TOTP 2FA Code Generator

Overview

Turns a base32 2FA secret into the current six-digit TOTP code, implementing RFC 6238 on top of Web Crypto HMAC-SHA-1. The code refreshes once a second against a thirty-second window, with a draining progress bar showing exactly how long the current code remains valid, and the secret stays on your device.

How It Works

Paste the base32 secret from a 2FA setup screen. The tool decodes it, derives the current time step, and shows the six-digit code with the seconds left before it rotates. A timer re-evaluates every second, so the code and the bar stay in sync without a reload. If the secret is not valid base32, or decodes to fewer than four bytes, an amber panel explains that only the letters A-Z and the digits 2-7 are allowed instead of showing a plausible but wrong code.

Step-by-Step Usage Guide

1. Copy the base32 secret from the provider's 2FA setup screen — usually shown as the 'can't scan the QR code?' text alternative, in blocks of four or eight characters.
2. Paste it in. Spaces and lowercase are common in those screens; the decoder handles the standard alphabet, and tells you if a character is outside A-Z or 2-7.
3. Read the six-digit code and check the bar. If only a few seconds remain, wait for the rotation rather than submitting a code that will expire in transit.
4. Copy the code with the button and use it immediately. Each code is valid for its own thirty-second window, and most servers accept only the current step or one adjacent step.

Technical Specifications & Standards

TOTP is HOTP (RFC 4226) with a clock instead of a counter. The counter is floor(unixSeconds / 30), packed big-endian into eight bytes and signed with HMAC-SHA-1 using the decoded secret. The resulting twenty-byte MAC is then reduced by dynamic truncation: the low nibble of the last byte selects a four-byte offset, the high bit of that word is masked off to avoid sign issues, and the remainder modulo 10^6 is left-padded to six digits. Base32 (RFC 4648) is used for the secret precisely because its alphabet omits the easily confused characters 0, 1, 8 and 9, which matters when a human retypes a code from a screen. Two consequences of the fixed parameters are worth knowing: this tool always uses SHA-1, six digits and a thirty-second period, which is what the overwhelming majority of providers use, so a provider configured for eight digits, SHA-256 or a sixty-second window will not match. And because the counter is derived from the device clock, a machine whose clock has drifted more than about thirty seconds will produce codes the server rejects even though the secret is correct.

Targeted Use Cases

• Verifying that an authenticator migration worked, by checking that a freshly imported secret produces the same code as the old device at the same moment.
• Testing a 2FA login flow in development without needing a phone in the loop for every run.
• Validating your own server-side TOTP implementation against an independent one that follows the same RFC.
• Diagnosing 'code rejected' reports, where comparing this code with the user's tells you whether the cause is a wrong secret or a drifted clock.

Notes & Gotchas

• Use this for testing and diagnosis, not as your everyday authenticator. The tool itself says so: a real second factor should live on a separate device from the browser you log in with.
• Never paste the secret for a production account you care about. If that secret leaks, the second factor is gone — and unlike a password, rotating it means re-enrolling.
• Check the device clock first when codes are refused. TOTP failures are far more often clock drift than a bad secret.
• Expect a mismatch if your provider is not on the defaults. Eight-digit codes, SHA-256 and sixty-second windows all exist, and none of them will line up with this tool's fixed SHA-1, six-digit, thirty-second parameters.

Frequently Asked Questions