How TOTP works
TOTP (Time-based One-Time Password, RFC 6238) turns a shared secret plus the current time into the rotating 6-digit code you know from authenticator apps. The mechanism: take the secret, take the current Unix time divided into 30-second steps, compute an HMAC of the two, and truncate the result to 6 digits. Because both you and the server share the secret and read the same clock, you both derive the same code independently — no network round-trip needed. The code changes every 30 seconds because the time-step input changes.
The inputs that must match
| Parameter | Common value | Notes |
|---|---|---|
| Secret | Base32 (A–Z, 2–7) | Provided by the service |
| Algorithm | SHA-1 | Some use SHA-256/512 |
| Digits | 6 | Occasionally 8 |
| Period | 30s | Rarely 60s |
If a code is rejected and the clock is correct, a mismatch in one of these (algorithm/digits/period) is the next thing to check — they’re all encoded in the otpauth:// URI a service gives you.
The Base32 secret
TOTP secrets are Base32 encoded (uppercase A–Z and digits 2–7 only). Characters like 0, 1, 8, 9, or lowercase letters aren’t valid Base32 and will trigger a decoding error — so if the tool rejects a secret, check you copied it exactly, without spaces or invalid characters. The otpauth://totp/...?secret=... URI bundles the secret with all the parameters above, which is what QR codes for 2FA setup actually encode.
No network, by design
To keep a zero network footprint, this tool derives time from your local device clock, not an external time server — which is exactly why clock drift (FAQ) is the main failure mode. All HMAC computation happens locally through the Web Crypto API. For the symmetric-crypto building block underneath TOTP, see the HMAC Generator.