TOTP Secret Generator (2FA)
Base32 shared secrets for TOTP two-factor authentication, plus the otpauth:// URI.
$ head -c 20 /dev/urandom | base32
Why base32, of all things
TOTP secrets are printed in base32 for one reason: humans have to type them. RFC 4648's base32 alphabet is uppercase letters and the digits 2 through 7 — it deliberately omits 0, 1, 8 and 9 precisely because they are the digits people confuse with O, I and B. It is less dense than base64, which nobody cares about, and it survives being read off a screen and typed into a phone, which everybody does. The QR code you usually scan is simply this same string wrapped in the otpauth:// URI printed above.
How long should it be?
20 bytes — 160 bits, 32 base32 characters — is the default here and what RFC 4226 requires as a minimum for HOTP, which TOTP builds on. Google Authenticator has historically accepted 10-byte secrets, and they are still far beyond guessing, but there is no reason to go below the spec. Going above 20 is harmless and equally pointless: HMAC-SHA-1 has a 160-bit output, so a longer key gets hashed down to the same strength.
What this secret does and does not protect
TOTP is a shared secret: the server holds the same value your authenticator app does. That is its structural weakness — a server breach exposes every user's second factor, and it is why TOTP does not stop a convincing phishing page, which simply asks you for the current code and replays it within its 30-second window. TOTP is a large improvement over a password alone and a poor substitute for a passkey or a hardware key, which are bound to the origin and cannot be relayed. Generate the secret once, let the user scan it, store it encrypted, and issue recovery codes — because a lost phone is far more common than an attacker.
Why is the secret in base32 and not base64?
Because people have to type it. RFC 4648's base32 alphabet is uppercase letters plus the digits 2–7, deliberately omitting 0, 1, 8 and 9 — the characters humans confuse with O, I and B. It is less compact than base64, which does not matter, and it survives being read off a screen, which does.
How long should a TOTP secret be?
20 bytes — 160 bits, 32 base32 characters — which is the default here and the minimum RFC 4226 specifies. Google Authenticator has historically accepted 10-byte secrets and they are still far beyond guessing, but there is no reason to go below the spec. Going above 20 is pointless: HMAC-SHA-1's output is 160 bits, so a longer key hashes down to the same strength.
Does TOTP protect against phishing?
No, and this is its main limitation. A convincing phishing page simply asks for the current code and replays it inside its 30-second window. TOTP is also a shared secret, so a server breach exposes every user's second factor. It is a large improvement over a password alone and a poor substitute for a passkey or a hardware key, which are bound to the origin and cannot be relayed.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.