How to use
Paste a base32 shared secret (`JBSWY3DPEHPK3PXP`) or an `otpauth://totp/...` URL (often encoded inside the QR code a service shows during 2FA setup). The current 6-digit code generates immediately, with a countdown ring showing how many seconds remain in the current 30-second window. The next code previews so you can avoid copying a code that is about to expire mid-paste.
Reach for this when you need a TOTP without installing an authenticator app on the current device — recovering access to a server, scripting a one-time login flow, or testing a 2FA integration during development. Note the security trade-off: an authenticator app sits in a separate, secured device (your phone) by design, and TOTP in the same browser as the login defeats much of the point. Use this for development, recovery, or scripted automation, not as your daily 2FA. Codes never leave the browser — all the HMAC-SHA-1 math runs locally.
Examples
Generate from a base32 secret
Input
secret: JBSWY3DPEHPK3PXP
algorithm: SHA-1
digits: 6
period: 30
Output
Current: 287082
Next: 615847
(20 seconds remaining in current window)
The defaults (SHA-1, 6 digits, 30-second period) match Google Authenticator, Authy, 1Password, and almost every other consumer 2FA app. RFC 6238 allows variations — SHA-256 / SHA-512 hashes, 7 or 8 digits, 60-second periods — but most services stay on the defaults because client interoperability matters more than the marginal security gain.
Parse an otpauth URL from a QR code
Input
otpauth://totp/GitHub:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=GitHub&algorithm=SHA1&digits=6&period=30
Output
Issuer: GitHub
Account: [email protected]
Secret: JBSWY3DPEHPK3PXP
Current: 287082
The URL format (`otpauth://totp/<label>?secret=<base32>&issuer=<name>&...`) is a Google Authenticator convention now followed by almost every TOTP issuer. Decode the QR with a scanner, paste the resulting URL here, and the issuer / account labels populate automatically. Useful when adding a TOTP secret to a password manager that does not have built-in QR scanning.
Manual base32 decode of secret bytes
Input
secret (base32): JBSWY3DPEHPK3PXP
raw bytes (hex): 48 65 6c 6c 6f 21 de ad be ef
Output
("Hello!" + 4 random bytes)base32 (RFC 4648) is the wire format for TOTP secrets because it uses only 32 characters (A–Z, 2–7), is case-insensitive, and lacks the visually confusing 0 / O / 1 / I. The actual HMAC operates on the decoded bytes, not on the base32 string — `JBSWY3DPEHPK3PXP` is just 10 bytes after decoding. Most issuers generate 20 random bytes (32 base32 chars).
FAQ
How does TOTP actually work?
TOTP (RFC 6238) is HOTP (RFC 4226) with the counter replaced by `floor(unix_timestamp / period)`. Both server and client share a secret and compute `HMAC-SHA-1(secret, counter)`, then extract a 6-digit decimal code using a dynamic-truncation step. Because both sides use the same time and the same secret, they arrive at the same code every 30 seconds. A drift of one window (±30 seconds) is usually tolerated server-side; longer drift means the codes diverge and the user has to re-sync.
TOTP vs HOTP — what is the difference?
HOTP increments a counter every time a code is generated; TOTP uses the current time as the counter. HOTP codes can be generated offline and used in any order (within a window), but the server has to track a sliding counter to detect replays and re-sync if the user generates extra codes. TOTP simplifies operations because both sides agree on the counter implicitly via the clock. Most consumer 2FA today is TOTP; HOTP shows up in older hardware tokens like RSA SecurID legacy devices.
Why is SHA-1 still used? Is it not broken?
SHA-1 collision resistance is broken (the 2017 SHAttered attack), but HMAC-SHA-1 remains secure because the attack model is different — an attacker would need to forge a tag without knowing the secret, not find two messages with the same plain hash. NIST kept HMAC-SHA-1 approved for MAC use through SP 800-107r1, and RFC 6238 still specifies SHA-1 as the default. Newer issuers can use SHA-256 or SHA-512, but every authenticator app supports SHA-1 while only some support the longer variants — so SHA-1 stays for interoperability.
My code is wrong even though the secret looks right
Three usual causes. **Clock drift**: TOTP needs the device clock to be within 30 seconds of NTP truth — check Settings / System Time and turn on automatic sync. **Padding**: some servers emit base32 secrets with trailing `=` padding, others strip it; both should decode equivalently but a few buggy implementations break on the wrong form. **Algorithm mismatch**: an `otpauth://` URL with `algorithm=SHA512` won't match an app generating SHA-1 codes. Use the otpauth form when given and trust the parameters it carries; do not override.
Is generating TOTP in the same browser as login risky?
Yes, partially. The "second factor" idea is that even if someone steals your password, they still need a separate device — your phone — to log in. If the TOTP secret lives in the same browser session as the password, a malware infection or browser-extension compromise can grab both at once. For day-to-day account security keep TOTP on a separate device (an authenticator app on the phone, or a hardware key like YubiKey). Use this web tool for development, scripted automation, recovery flows when you no longer have the phone, or staging environments where the threat model is different.
TOTP vs WebAuthn / passkeys — which is better?
WebAuthn (and its passkey UX layer) is strictly more secure for most use cases. TOTP shares a secret between server and client, so a database breach or a phishing site that proxies the request can steal the second factor. WebAuthn uses public-key crypto bound to the origin, so a passkey for `github.com` cannot be replayed against `github.evil.com` even if the user is fooled. The TOTP advantage today is breadth: every legacy service supports it, hardware tokens for it are cheap, recovery flows are well-understood. New systems should default to passkeys with TOTP as a fallback, not the other way around.
Related concepts
TOTP (Time-based One-Time Password, RFC 6238, May 2011) is a small wrapper over HOTP (RFC 4226, 2005). Both derive a 6-digit code from a shared secret using HMAC-SHA-1 plus dynamic truncation; the difference is the counter. HOTP increments a counter per code; TOTP computes the counter from `floor(unix_time / 30)`. The 30-second window is the de facto standard but not mandated — the period parameter in the otpauth URL can change it. Most authenticator apps assume 30 seconds and ignore other values.
Three implementation details matter day to day. The shared secret is exchanged out-of-band, usually via a QR code containing an `otpauth://totp/<label>?secret=<base32>&issuer=<name>&algorithm=SHA1&digits=6&period=30` URL. The QR code itself is just a transport — once you decode it the secret is plain base32. Server verification typically accepts ±1 window of drift to handle slight clock skew. Backup codes (one-time scratch codes the user prints during setup) are the standard recovery path when the phone is lost.
Three adjacent technologies surround TOTP. **HOTP** is the counter-based ancestor, still used in some hardware tokens (RSA SecurID legacy, Yubico HOTP slot). **SMS-based 2FA** delivers the code over text message; it is convenient but vulnerable to SIM swap attacks and is being deprecated by NIST (SP 800-63B) for high-value accounts. **WebAuthn / passkeys** (FIDO2) use public-key crypto bound to the relying-party origin, making phishing structurally impossible — the second-factor world is moving here, with TOTP as the long-tail fallback for services that have not migrated. Hardware tokens like YubiKey support all three (TOTP slots via OATH-HOTP / OATH-TOTP, plus FIDO2).
