TOTP / 2FA

About the TOTP / 2FA

The TOTP generator produces everything needed to set up or test time-based one-time password authentication: a random base32 secret, a scannable otpauth:// provisioning QR code, and a live 6-digit code that rotates on a 30-second countdown. It implements RFC 6238 (HMAC-SHA1, 6 digits, 30-second step), the same standard used by Google Authenticator, Authy, 1Password and most 2FA apps.

People reach for it in a few situations: bootstrapping 2FA while building a login flow, verifying that a server-side TOTP implementation produces the same codes as a known-good client, or reading the current code for a secret they already have without opening an authenticator app. You can generate a fresh secret or paste an existing base32 value and watch its live code and remaining seconds.

What sets it apart from most "totp online" tools is that it does the actual RFC 6238 math, not a canned demo. It calls the browser's Web Crypto API directly (crypto.subtle.importKey and sign with HMAC-SHA1) to compute each code, and it renders the otpauth:// QR itself rather than round-tripping through a third-party QR service.

On privacy: this tool has no server route. There is no api/totp endpoint in this app, so a secret you type or generate is never sent over the network. The QR code is drawn locally as SVG and the code is computed locally with Web Crypto. Nothing about a secret or a code leaves the tab it runs in. That said, treat any web page, including this one, as unsuitable for a secret protecting an account you actually care about (see the security section below for why).

How to use it

1. Open the tool; a random 20-byte base32 secret is generated automatically.
2. Set issuer and account labels, these are only used to label the entry in your authenticator app.
3. Scan the otpauth:// QR code with an authenticator app, or copy the secret to add it manually.
4. Read the live 6-digit code and the countdown bar showing seconds left in the current 30-second window.
5. To check a secret you already have instead of a new one, paste its base32 value into the secret field.
6. Compare the code shown here against your own server's TOTP output for the same secret to confirm your implementation is correct.
7. Click copy secret if you need the raw base32 value for storing in a password manager or config file.

Examples

• Generate a fresh secret and scan the QR into Google Authenticator or Authy to enroll a throwaway test account.
• Paste the classic test secret JBSWY3DPEHPK3PXP to see its current live 6-digit code and countdown.
• Set issuer to Acme Staging and account to test@acme.dev before generating the QR, so the entry is labeled clearly in your app.
• Feed the same secret and current Unix time into your own server code, and check the digits match what this tool shows.
• Watch the bar turn amber in the last 5 seconds and time entering a code right after it flips to a fresh window, to rule out timing as the cause of a failed login.
• Paste a secret with stray spaces or lowercase letters to confirm the tool still decodes it, since base32 input is normalized before use.

How TOTP works: RFC 6238 step by step

TOTP (RFC 6238) is a small extension of HOTP (RFC 4226): instead of an incrementing counter, the counter is derived from the current time. Every 30 seconds the counter advances by one, so a fresh code appears each interval without any communication between the app and the server.

The steps this tool actually runs: take the current Unix time, divide by the period (30 seconds) and floor it to get a counter. HMAC that counter (as an 8-byte big-endian value) with the secret using SHA-1, producing a 20-byte digest. Take the low nibble of the last byte as an offset, read 4 bytes starting at that offset, mask off the top bit, and reduce the result modulo 10^6 to get a 6-digit code, padded with leading zeros if needed. This is the same "dynamic truncation" defined in RFC 4226 section 5.3.

Because the code depends only on the shared secret and the current time, no state needs to be exchanged after enrollment. That is also why clock accuracy matters more than for most protocols, see the drift section below.

• Time step (period): 30 seconds, the RFC 6238 default and what virtually every consumer authenticator app expects.
• Hash algorithm: HMAC-SHA1, the default in the RFC and the only algorithm this tool computes. Some enterprise systems use HMAC-SHA256 or SHA512 instead, which produce different, incompatible codes for the same secret.
• Code length: 6 digits, the common default. RFC 4226 also allows 7 or 8 digits, again incompatible with a 6-digit verifier for the same secret.
• Counter derivation: floor(unix_time / period), an integer that only changes once per period, not a continuously running clock.

Secret formats: why base32 and not base64 or hex

TOTP secrets are almost always distributed as base32, using the alphabet A-Z and 2-7 (RFC 4648 section 6), rather than base64 or raw hex. This tool generates 20 random bytes (160 bits, the length RFC 4226 recommends as a minimum) and base32-encodes them into the secret field.

Base32 was chosen for this use case for practical reasons rather than cryptographic ones: it is case-insensitive so it survives being typed, printed or read aloud without ambiguity, it avoids the visually confusable characters 0, 1, 8 and 9 that hex and base64 don't exclude, and every authenticator app's manual-entry field expects it. A base64 or hex string pasted into an authenticator app's secret field simply will not produce matching codes.

When pasting an existing secret into this tool, stray whitespace, dashes or lowercase letters are normalized automatically. What it cannot fix is padding-corrupted or truncated secrets, if a secret was copied with characters missing, the decoded key bytes will differ and every code produced from it will be wrong.

• Base32: A-Z and 2-7 only, case-insensitive, no padding required for a full byte-aligned secret. Standard for otpauth:// secrets.
• Base64: uses +, / and possibly =, case-sensitive. Not accepted by authenticator apps' manual secret entry.
• Hex: 0-9 and a-f. Sometimes used internally by libraries, but not what you paste into an authenticator app.
• Recommended secret length: at least 128 bits (16 bytes), RFC 4226 recommends 160 bits (20 bytes) minimum, which is what this tool generates by default.

Security: do not paste production secrets into random online tools

A TOTP secret is a long-lived credential, anyone who has it can generate valid codes for that account indefinitely, unlike a password that can be rotated on suspicion of leak without also touching every dependent system. That makes the secret itself, not just the 6-digit code, the actual thing worth protecting.

Pasting a real account's secret into an unfamiliar web tool is a bad habit even when the tool claims to be client-side, because you generally cannot verify that claim without reading the source. For this specific tool: there is no server-side route for it (no app/api/totp in this codebase) and the component makes no fetch or XHR calls, the code and secret are computed with the browser's Web Crypto API and never leave the page. You can confirm this yourself with your browser's network tab, no requests fire when you generate a secret or read a code.

Even so, treat this tool (and any online TOTP tool) as suitable for enrollment testing, debugging a server implementation, or working with disposable test accounts, not as a place to park the 2FA secret for your email, bank or password manager. For those, enroll directly from the service into a dedicated authenticator app or hardware key, and keep the secret out of clipboards, chat logs and browser tabs altogether.

• Good use: generating a secret for a new test account, or reading the live code of a secret already used only for development.
• Good use: verifying your own server's TOTP implementation matches a known-good client by comparing outputs for the same secret and time.
• Bad use: pasting the secret behind an existing production or personal account into any online tool, including this one.
• Bad use: storing a real secret's QR code or base32 string in a shared document, ticket or chat thread.

Debugging "my code doesn't work": clock drift and other causes

When a generated code is rejected, the cause is almost always one of a handful of things, in rough order of likelihood. Because TOTP has no error-correction, a wrong code gives no hint about which of these is at fault, so it helps to check them in order.

Clock drift is the most common cause on real deployments: TOTP assumes the device generating the code and the server verifying it agree on the current time to within a few seconds. If a server's or phone's clock has drifted (unsynced NTP, a VM that lost time after a pause, a phone with automatic time off), the counters no longer line up and every code fails even though the secret is correct. Most server-side verifiers accept a small window, commonly the current step plus or minus one (so roughly 90 seconds of tolerance for a 30-second period), specifically to absorb this. If codes fail consistently rather than intermittently, drift beyond that window is the first thing to check, not the secret.

• Clock drift: device and server disagree on the time by more than the verifier's tolerance window (usually plus or minus one 30-second step). Fix: sync both clocks via NTP.
• Wrong secret encoding: the secret was copied as base64 or hex instead of base32, or has characters missing. Fix: re-copy the exact base32 string from the original QR or manual-entry text.
• Stale code: the code was generated correctly but submitted after the 30-second window rolled over. Fix: read the countdown and enter the code with a few seconds to spare.
• Algorithm or digit-count mismatch: the server expects SHA-256/SHA-512 or 7-8 digits, but the client (or this tool) computes SHA-1/6 digits. Fix: confirm the server's TOTP parameters match what the client generates.
• Time zone confusion: TOTP is computed from Unix time (UTC), local time zone is irrelevant. A "time zone bug" report is usually actually a clock-sync or DST-transition issue, not a zone-offset one.

Frequently asked questions