TOTP Secret Generator: Base32 Keys and otpauth URIs

How to use the totp secret generator

1. Choose the secret length: 16 characters provides 80 bits of entropy, 20 gives 100 bits, and 32 gives 160 bits.
2. Enter the issuer (your service name) and account (username or email) to label the entry in authenticator apps.
3. Click Generate to produce a new random Base32 secret.
4. Copy the Base32 secret to enter it manually, or use the otpauth URI to create a QR code for scanning.

How Base32 secrets work

TOTP (Time-based One-Time Password) relies on a shared secret between the server and the authenticator application. This secret is encoded in Base32, which uses the letters A through Z and the digits 2 through 7. Base32 is chosen because it leaves out the digits 0, 1, 8 and 9, so an O or an I in a secret is always the letter and never a zero or a one. That reduces transcription errors when typing a secret by hand.

Each Base32 character represents exactly 5 bits of data. Therefore, a 16-character secret holds 80 bits of entropy, a 20-character secret holds 100 bits, and a 32-character secret holds 160 bits. RFC 4226 requires a shared secret of at least 128 bits and recommends 160 bits, which only the 32-character option meets. The 16 and 20 character options are offered because some authenticator apps and older systems still use 80 and 100 bit secrets.

The otpauth URI format

The otpauth URI is a standardized string that tells an authenticator app everything it needs to set up an account. Its structure follows this pattern:

otpauth://totp/ISSUER:ACCOUNT?secret=BASE32SECRET&issuer=ISSUER

The path contains the issuer and account separated by a colon. The query parameters include the Base32 secret and the issuer again. When you feed this URI into a tool like the QR code generator, the resulting QR code can be scanned directly by apps such as Google Authenticator, Authy or Aegis. If you need to verify the codes produced by your new secret, you can use a totp generator to compute the six-digit values.

Secret length comparison

Different lengths offer different levels of brute-force resistance. Here is how the common sizes compare:

For new systems choose 32 characters (160 bits), the length RFC 4226 recommends. The shorter options exist so you can match an authenticator app or server that already expects 16 or 20 characters.

Storing and handling secrets safely

A TOTP secret is equivalent to a password. Anyone who obtains it can generate valid authentication codes. Store secrets securely on the server side, ideally encrypted at rest. Never log them in plain text or expose them in client-side JavaScript after initial setup.

When provisioning a user, display the secret or its QR code only once during enrollment. After the user confirms their authenticator is working, discard the plain-text representation from memory. If you are building a system that issues these secrets, consider pairing them with other cryptographic tools like an HMAC-SHA256 generator for signing related payloads.

Common mistakes to avoid

Several pitfalls cause TOTP setups to fail silently. First, ensure the Base32 string does not contain padding equals signs if your library expects raw input. Second, the issuer parameter in the URI must match the issuer in the path prefix; mismatches cause some apps to display blank labels. Third, URL-encode special characters in the account name or issuer. Spaces must become %20 (not +), and symbols like & or + must be percent-encoded to prevent breaking the URI parser. This tool also encodes @, which apps decode correctly.

Finally, remember that the server clock and the authenticator clock must be loosely synchronized. Most implementations allow a window of one time step (30 seconds) in either direction to account for minor drift.

Worked examples