TOTP / 2FA Code Generator

About this tool

This tool computes the current TOTP value per RFC 6238 from a Base32 shared secret, using HMAC over a time-based counter. It is meant for verifying and debugging 2FA setups — confirming that a server, an authenticator app, and your understanding of the configuration all agree. It is not a replacement for an authenticator app, because it stores nothing: refresh the page and the secret is gone. Everything runs locally in your browser and the secret is never uploaded — but a TOTP secret is a credential (anyone holding it can generate valid codes), so prefer disposable test secrets over your real account seeds.

How it works

The Base32 secret is decoded to the raw key bytes. A counter is derived as floor(unixtime / period) — so the counter advances once per period. An HMAC (SHA-1, SHA-256, or SHA-512) is computed over the 8-byte big-endian counter using the key. The standard dynamic-truncation step reads the low nibble of the last HMAC byte as an offset, extracts four bytes from that offset, masks the high bit, and reduces the result modulo 10^N to produce the N-digit code. Because the counter changes with time, the code rotates every period seconds.

Common use cases

• Confirm your authenticator app matches the server: generate a code here from the same secret and check it lines up with what the server expects and what your app shows.
• Debug a 2FA implementation you are building: compare your server's generated/accepted codes against a known-correct RFC 6238 reference for the same secret, digits, period, and algorithm.
• Generate test codes in development: use a fixed test secret to log in to a 2FA-protected environment during local development without scanning a QR code into a phone.

Common mistakes

• Treating the secret as non-sensitive: the Base32 secret is the 2FA credential. Anyone who has it can generate valid codes, so handle it like a password and avoid pasting production seeds here.
• Clock skew between client and server: TOTP depends on accurate time. If your system clock is off by more than the server's tolerance window, codes are rejected even though they are computed correctly.
• Mismatched digits, period, or algorithm: a service using 8 digits, a 60-second period, or SHA-256 will reject a code generated with different parameters. Match all three to the service's configuration.

FAQ

Is the secret sent anywhere?
No — the code is computed locally in your browser with the Web Crypto API; nothing is transmitted or stored.

Is this a replacement for Google Authenticator?
No — it does not store secrets or persist anything; use it to test and verify, not as your everyday authenticator.

My code is rejected — why?
Most often clock skew (check your system time), or the wrong period/digits/algorithm; the defaults 6 digits / 30s / SHA-1 match almost all services.