Those 6-Digit Codes, Demystified
You open Google Authenticator and there’s a number: 847293. It ticks down, vanishes, and a completely different number appears: 152637. You type it into a login form and you’re in. But how does your phone and the server independently produce the same number at the same time?
The answer is TOTP — Time-based One-Time Password, defined in RFC 6238. Both sides share a secret (usually a Base32-encoded string). They take the current Unix timestamp, divide by 30, feed that counter into HMAC-SHA1 along with the secret, and extract 6 digits from the result. Same secret + same time = same code.
This tool does exactly that. Enter a Base32 secret (or generate a random one), and it produces live TOTP codes with a countdown timer. It also outputs the OTPAuth URI — the standard format authenticator apps expect when you scan a QR code.
Building and Testing 2FA
You’re implementing two-factor authentication on your web app. Your server generates TOTP codes from the user’s secret, and the user’s authenticator app does the same. When the codes match, the second factor passes.
The tricky part is getting your server-side implementation right. Off-by-one errors in the time counter, wrong Base32 decoding, or HMAC computed with the wrong hash algorithm will all produce incorrect codes. Here’s how to debug it:
- Generate a random secret in this tool.
- Add the same secret to Google Authenticator (paste it in manually or use the OTPAuth URI).
- Verify that both this tool and Google Authenticator show the same code at the same time.
- Feed that secret into your server-side code. If the server produces a different code, your implementation has a bug.
The most common issue is clock skew. TOTP is sensitive to time differences of more than 30 seconds. If your server clock drifts, codes will mismatch. Most production implementations accept the previous and next codes as well (a “window” of 1), which gives you 90 seconds of tolerance.
The OTPAuth URI Format
When users set up 2FA, they usually scan a QR code. That QR code contains a URI like:
otpauth://totp/YourApp:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=YourApp
The secret is Base32-encoded. The issuer and account name show up in the authenticator app so users can tell their accounts apart. This tool generates the URI for you — feed it to a QR code generator and you’ve got a scannable setup code.
Why SHA-1 in 2026?
Yeah, SHA-1 is broken for collision resistance. But TOTP doesn’t need collision resistance — it uses HMAC-SHA1, which has a different security requirement (key-dependent unforgeability), and HMAC-SHA1 is still considered safe for that purpose.
More practically, Google Authenticator only supports SHA-1 by default. RFC 6238 technically allows SHA-256 and SHA-512, but most authenticator apps either don’t support them or require special configuration. Stick with the defaults unless you’ve got a specific reason not to.
The secret is the real security gate. Treat it like a password. Anyone with the secret can generate valid codes. All computation here runs client-side — the secret never leaves your browser.
For generating the secrets in other formats, the Random Token Generator on Toolsvu produces cryptographic random strings. The Password Generator creates strong passwords for the accounts those 2FA codes protect.