TOTP Code Generator
Generate live 2FA codes from a base32 secret, with countdown, drift checking and otpauth:// parsing.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
TOTP (Time-based One-Time Password, RFC 6238) is the algorithm behind authenticator apps: the server shares a base32-encoded secret with you once, and from then on both sides compute a code from that secret plus the current time — a new code every 30 seconds by default. This tool generates the code live with a countdown, validates a code with ±1-step clock-drift tolerance the way real servers do, and decodes or builds otpauth:// provisioning URIs. It implements the RFC faithfully: HMAC-SHA-1/256/512, 6 or 8 digits, and the dynamic truncation from RFC 4226. The secret never leaves your browser.
How it works
T = ⌊ Unix time ÷ 30 ⌋ code = HMAC-SHA1(secret, T) → truncate to 31 bits → mod 10^digits
A TOTP code is an HMAC of the current 30-second time step, keyed with the shared secret and cut down to 6 or 8 digits. Your authenticator and the service compute matching expected codes independently; you still submit the generated code to the service when signing in.
| Question | Working | Answer |
|---|---|---|
| 8-digit code for the RFC 6238 test secret at 59 seconds after the epoch | T = ⌊59 ÷ 30⌋ = 1 | 94287082 |
When to use it
Questions
Why does the code change every 30 seconds?
The counter is floor(unix-time / 30). Every 30 seconds the counter ticks, the HMAC input changes, and a completely new code appears. Both your app and the server count the same windows from the same secret, so they agree without exchanging traffic. The countdown shows when the current window ends — type fast when it turns red.
My code is rejected even though the app shows one — why?
Check the secret, algorithm, digit count and period against the service settings, then check your device clock. A mismatch in any of these can cause rejection. This tool checks the current step and its two neighbors (±1); a real service chooses its own acceptance window and replay rules. Matching here does not prove the service will accept a code.
What is a base32 secret, and why do 0, 1, 8 and 9 never appear?
Base32 (RFC 4648) encodes bytes using only A-Z and 2-7 — 32 characters that survive transcription. The digits 0, 1, 8 and 9 are excluded, but the letters O and I are valid. Standard Base32 uses = padding when required; this tool tolerates lowercase, spaces and missing padding when you paste.
What is the otpauth:// URI my service showed as a QR code?
It is the provisioning format Google Authenticator standardized: otpauth://totp/Issuer:account?secret=BASE32&issuer=Issuer&algorithm=SHA1&digits=6&period=30. The QR code is just this URI; scanning it delivers the secret to your app. Paste one into the URI tab to read its parameters, or build one from fields to hand a secret to someone else's app.
Which algorithm should I choose — SHA-1, SHA-256 or SHA-512?
Whatever your service provisions. In practice that is nearly always SHA-1: Google Authenticator ignored the algorithm parameter for years, so the ecosystem standardized on it, and HMAC-SHA-1 in this construction is not broken for OTP purposes. SHA-256/512 are supported for services that explicitly use them — but switching algorithms on your own without the server matching means every code fails.
Are backup codes related to TOTP?
No — backup codes are static one-time passwords your service generates and displays once, stored server-side. They exist because TOTP can fail: lost phone, dead battery, clock drift, deleted profile. Save them somewhere safe when you enroll a new 2FA secret; they are your way back in when the TOTP secret itself is gone.