TOTP Code Generator (2FA)

What a TOTP code really is

The six-digit codes you copy from an authenticator app are Time-based One-Time Passwords (TOTP), defined by the internet standard RFC 6238. They are not random and they are not sent over the network — each one is a deterministic function of two ingredients: a secret key shared once when you set up two-factor authentication, and the current time. Your device and the login server each compute the same code independently from those same two inputs. When they match, the server knows you possess the secret without the secret ever travelling across the wire. This tool implements that computation in your browser so you can generate the codes yourself from a Base32 secret.

The six steps, with a worked walkthrough

Here is exactly what the tool does each time it produces a code, following RFC 6238:

1. Make a time counter. Take the current Unix timestamp (seconds since 1970) and integer-divide by 30. At 12:00:30 UTC on a given day that yields some large integer T; for the next 30 seconds T stays fixed, then ticks up by one.
2. Encode T as a big-endian 64-bit integer (eight bytes, most significant first).
3. Decode the secret from Base32 back into raw bytes.
4. Compute HMAC-SHA1 of the counter using the secret as the key. This is the cryptographic core, and the tool runs it with the browser's Web Crypto API.
5. Dynamic truncation. Read the last 4 bits of the 20-byte HMAC as an offset, then pull four bytes starting at that offset and mask off the top bit to get a 31-bit number. The variable offset is what stops an attacker from predicting which part of the hash matters.
6. Take it mod 1,000,000 and zero-pad to six digits. That final remainder is your code.

The tool displays the current code split into two groups of three for readability, and — usefully — also computes the next code by running the same six steps with T + 1, so you can see what's coming before the window flips.

Why Base32, and why HMAC-SHA1

The secret is shared in Base32 (the alphabet A–Z and 2–7) rather than the more familiar Base64 because Base32 avoids easily-confused characters and is case-insensitive, which makes a secret safe to read aloud, type by hand, or print on a backup card. SHA-1 surprises people because it is broken for collision resistance — but TOTP uses it inside HMAC, a keyed construction where SHA-1's collision weakness does not apply, and the standard mandates it for interoperability. Every mainstream authenticator uses the same HMAC-SHA1 default, which is why a code generated here will match Google, GitHub, or any other service that issued the secret.

The 30-second window and clock drift

Because T changes every 30 seconds, so does the code. The countdown ring shows how many seconds remain in the current step, turning red in the final five. The single most common reason a freshly generated code is rejected is clock drift: TOTP assumes your device's clock agrees with the server's to within a step. If your computer's time is off by more than 30 seconds you will compute a code for the wrong window and login will fail. Most servers tolerate a one-step slack on either side, but the fix is simply to keep your device clock synchronised to network time.

Privacy and where the secret lives

Every calculation happens locally through the browser's Web Crypto API — the secret is never transmitted to any server, and you can confirm this by turning off your network connection and watching codes keep generating. Accounts you add are saved in the browser's local storage so they persist between visits, which has a direct security consequence: anyone with access to this browser profile can read those secrets. Treat a TOTP secret exactly like a password.

Practical tips

• Use this as a backup, not your primary device. The point of two-factor authentication is a second factor on a separate device. Generating codes in the same browser you log in from weakens that separation, so keep your phone's authenticator as the main method and use this for recovery.
• Paste the secret, don't transcribe it. When a service shows a QR code there is usually a "can't scan?" link revealing the Base32 secret as text — copy that exactly. A single wrong character produces valid-looking but always-wrong codes.
• Verify against a known account first. Add one account whose codes you can cross-check against your phone; if they match, your clock and secret are correct and you can trust the rest.

Common mistakes

• Including spaces or formatting from the secret. Services often print the Base32 secret in groups of four for readability. The tool strips whitespace, but stray non-Base32 characters will break decoding — paste only the letters and digits 2–7.
• Blaming the tool for a rejected code. If codes never match, the cause is almost always an unsynced clock or a mistyped secret, not the algorithm — every step here follows RFC 6238 exactly.
• Storing high-value secrets in a shared browser. Local storage is convenient but not encrypted. On a shared or public computer, add the account, use the code, then delete it — or don't store it there at all.