TOTP Generator
Generates the current TOTP/HOTP code from a Base32 secret, with a live countdown to the next one.
Paste the Base32 secret shown when activating 2FA — spaces, hyphens and a trailing "=" are ignored.
Enter a valid secret to see the current code.
Simulate the activation QR
The QR shows up here
What TOTP is (RFC 6238)
TOTP (Time-based One-Time Password) is the algorithm behind the 6-digit code that changes every 30 seconds in apps like Google Authenticator, Authy or 1Password. Defined by RFC 6238, TOTP is an extension of HOTP (RFC 4226, see "TOTP vs. HOTP" below) that uses the current instant — not a manual counter — as input: Unix time divided by the period (30s by default) becomes a counter that changes every interval, letting client and server reach the same code with no communication between them during verification, just a shared secret and a reasonably synchronized clock.
How the algorithm works: HMAC + dynamic truncation
The core is an HMAC (hash-based message authentication code) computed over the counter, using the secret as the key — the same primitive used to sign a JWT or verify a webhook. The HMAC result (20 to 64 bytes, depending on the hash algorithm) goes through "dynamic truncation" (RFC 4226 §5.3): the HMAC's last byte picks an offset, 4 bytes from that offset become a 31-bit number, and that number is reduced by the remainder of dividing by 10 raised to the digit count — that final reduction is what turns a HMAC of dozens of bytes into a short, readable code (6-8 digits).
Why the secret is Base32
A TOTP secret is a sequence of random bytes (typically 160 bits/20 bytes) — but raw bytes aren't typeable or easy to read in a 2FA app. Base32 (RFC 4648) solves that: it uses only 32 symbols (A-Z and 2-7), with no case distinction and no visually ambiguous characters like 0/O or 1/I/l — which is why a Base32 secret is safe to type by hand or read aloud, unlike Base64 (which uses symbols like +, / and is case-sensitive). This tool accepts the secret with or without the spaces/hyphens some services use to display it in 4-character blocks, and ignores the optional trailing "=" padding.
TOTP vs. HOTP: time vs. manual counter
HOTP (RFC 4226, the older standard, from 2005) uses a counter that increments with every code generated — the mechanism behind physical tokens with a button (pressing the button generates the next code, incrementing the counter once). TOTP (RFC 6238, from 2011) replaces that manual counter with time: instead of waiting for a click, the counter is derived automatically from the clock, split into fixed windows (30s by default) — no button needed, but it requires client and server clocks to be synchronized within a small tolerance. Practically every app-based 2FA uses TOTP; HOTP survives in some older hardware tokens.
Frequently asked questions
No. All generation happens locally in your browser, via the native Web Crypto API (crypto.subtle) — this tool makes no network calls, and the secret is never saved anywhere (not even localStorage): reload the page and it's gone.
30 seconds is the market-standard period, chosen as a balance between security (a short-lived code narrows the window an attacker who intercepts it can use) and usability (enough time to read and type the code before it expires). The period is configurable in the advanced options, but only works if the service on the other end uses the exact same value.
Yes, in the context of TOTP. SHA-1 is weak against collision attacks (two different inputs producing the same hash) — the reason it was phased out of certificates and signatures. TOTP doesn't rely on that property: it uses SHA-1 inside an HMAC, whose security depends only on the output being unpredictable to someone without the secret key, not on collision resistance. That's why every major 2FA app (Google Authenticator, Authy, 1Password) still defaults to SHA-1, decades after the algorithm was retired elsewhere.
The most common causes, in order of frequency: (1) the secret pasted here is incomplete or wrong — check it character by character; (2) your device's clock is out of sync (TOTP depends on precise time) — use this tool's previous/next codes to spot drift; (3) algorithm, digit count or period different from what the original service configured — check the advanced options.
Technically yes (the QR generated here is readable by any real 2FA app), but that isn't the main point — the normal activation flow already hands you the secret hidden behind a QR generated by the service itself. This tool exists for the reverse scenario: you already have the secret in hand (extracted, saved in a backup, or revealed as text by the service) and want to debug an integration or recover access without reaching for your phone.
See "TOTP vs. HOTP" above — in short, TOTP derives the code from time, with no manual step; HOTP derives it from a counter you control.
Neither value comes from a strict mathematical requirement of the algorithm — they're market conventions set by Google Authenticator, the first popular TOTP app, and replicated across the ecosystem ever since. 6 digits balance security (a 1-in-a-million chance of guessing per attempt) with fast typing; 30 seconds balances a short exposure window with a comfortable reading time.
Yes — they're real parameters of RFC 6238, available in the advanced options. But the service on the other end (whatever originally generated the secret) needs to use the exact same values, or the codes will never match — most real services never stray from the default (6 digits, 30s, SHA-1), so only change this if you know the specific service uses a different configuration.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.