TOTP Generator
Convert a Base32 secret into live two-factor codes, with a countdown and a clock-skew check. Works offline — the secret stays on this page.
Enter a secret to begin
——How a TOTP code is computed
TOTP is HOTP with the counter replaced by the clock. The algorithm is short enough to state in
full: take the Unix time in seconds, divide by the period (30 by default) and round down — that
integer is the counter. Encode it as an 8-byte big-endian value, compute
HMAC-SHA1(secret, counter), then take the last byte of the digest, use its low nibble
as an offset, read four bytes from that offset, mask off the top bit, and take the result modulo
10^digits. Zero-pad to the digit count.
That is the whole of RFC 6238. Both sides compute the same thing from the same shared secret and the same clock, so no network round trip is needed and no per-code state has to be stored.
Why SHA-1 is still the default
It looks like a red flag, but HMAC-SHA1 is not affected by the collision attacks that retired SHA-1 for signatures. TOTP needs a keyed MAC, not collision resistance, and HMAC-SHA1 remains sound for that purpose. SHA-256 and SHA-512 variants exist and are supported by RFC 6238, but plenty of authenticator apps only implement SHA-1 — so SHA-1 is what interoperability demands. The real secret to protect is the shared key, not the hash choice.
Clock skew, and why the previous window matters
The code is only valid for one period, which means a client whose clock is off by more than about a period will be rejected. Real servers accept the current window plus one on either side, so a code entered at second 29 still works a few seconds later. This page shows the previous and next window for exactly that reason: if your code is rejected and the neighbouring one works, you are looking at clock drift, not a wrong secret.
Handling the secret properly
- It is a credential, not an identifier. Anyone with the Base32 secret can generate valid codes forever. Treat it like a password — never in a ticket, a screenshot or a chat message.
- Store it encrypted at rest. If you generate secrets for users, encrypt them; a database leak that includes TOTP secrets silently defeats the second factor for every account.
- Accept one window either side, then stop. Replay protection is the point of the one-time property: a used code must be refused, and the accepted window must be narrow.
- Rate limit verification. A six-digit code has a million possibilities — brute force is only impractical because the window is 30 seconds and attempts are capped.
- Ship recovery codes. Losing the phone must not mean losing the account.
FAQ
Is my secret sent anywhere?
No. The HMAC is computed with the browser's Web Crypto API inside this page, and there is no network request at all. The code keeps updating when you disconnect from the internet — the easiest way to confirm it.
My code is always rejected — what is wrong?
In order of likelihood: the clock on this device is off (check it against an NTP source), the secret was transcribed with a missing or extra character, or the service expects different digits or period values than the defaults. Compare the next window first — if that one is accepted, it is a clock problem.
Do the spaces or lowercase in the secret matter?
No. Authenticator apps display secrets in groups of four for readability, and case is ignored. This tool strips spaces, hyphens and padding and upper-cases the rest before decoding.
Why six digits rather than eight?
Six digits give a 1-in-a-million chance per guess; eight make it 1-in-a-hundred-million. With a 30-second window and rate limiting, six is enough, and it is what users can type accurately. Eight is available here for services that require it.
Is this the same as the codes my bank sends by SMS?
No. Those are server-generated and delivered out of band. TOTP is derived from a shared secret and the clock, so it works with no connectivity — but it also means whoever holds the secret can generate codes, which is what makes a leaked secret so damaging.