Numbers
TOTP Secret Key Generator
A TOTP secret key generator produces the Base32-encoded shared seed that connects your server to an authenticator app like Google Authenticator, Authy, or Microsoft Authenticator. When a user scans a QR code during 2FA enrollment, this string is what gets transferred — both sides then derive the same six-digit code every 30 seconds without any network call. Developers building two-factor authentication need a unique, high-entropy secret per user account. This tool generates multiple secrets at once at a length you control. The default 32 characters gives 160 bits of entropy, matching what most TOTP libraries expect and exceeding the 128-bit minimum in RFC 4226. Use these freely for development, staging, and testing — not for live production accounts.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the count field to the number of secret keys you need — for example, 10 if seeding a batch of test users.
- Set the length field to your target character count; leave it at 32 for standard 160-bit TOTP compatibility.
- Click Generate to produce your Base32 secret keys as a list.
- Copy individual keys or the full list, then paste them into your database seed script, test fixture, or QR code generator.
Use Cases
- •Seeding a staging database with unique 2FA secrets for 50 test user accounts
- •Pasting a key into pyotp or otplib to verify your TOTP validation logic in unit tests
- •Populating an otpauth:// URI and QR code to test authenticator app scanning end-to-end
- •Supplying realistic Base32 secrets in API documentation and Postman collection examples
- •Generating demo secrets for a security-awareness training session on 2FA enrollment flows
Tips
- →Generate secrets at length 32 by default; only go to 64 if a specific hardware token or spec explicitly requires longer seeds.
- →Combine a generated secret with the pyotp or otplib verify function immediately — confirm the library accepts it before building enrollment logic around it.
- →When using secrets for QR code demos, pair them with a fixed account name and issuer in the otpauth URI so the authenticator app labels them clearly.
- →Generate a batch of 20-50 keys at once to populate a test-user seed file; it's faster than running the generator repeatedly for each row.
- →Never log generated secrets in console output or test reports, even in development — build that discipline early so it carries into production code.
- →If your TOTP library throws an invalid-secret error, check that you haven't accidentally included padding characters (=) — strip them before storing or passing the key.
FAQ
What length should a TOTP secret key be?
RFC 6238 recommends a shared secret of at least 128 bits, and 160 bits (a 32-character Base32 string, the default here) is the common standard used by Google Authenticator and most apps. Longer is fine; shorter than 128 bits weakens the secret. Keep the default 32 characters unless your system specifies otherwise.
Are these TOTP keys cryptographically strong?
Yes — the keys are generated with the Web Crypto API (crypto.getRandomValues) and Base32-encoded, giving genuine cryptographic randomness suitable for real two-factor secrets. They are produced locally in your browser and never transmitted. As with any secret, store it securely and never log or share it in plaintext.
How do I turn a TOTP secret into a QR code for Google Authenticator?
Build an otpauth:// URI — otpauth://totp/Label?secret=YOURKEY&issuer=YourApp — and encode that string as a QR code with any QR generator or library. Scanning it adds the account to Google Authenticator, Authy, or 1Password. The secret is the Base32 string this tool produces; the rest of the URI is metadata.
Why is the key Base32-encoded?
TOTP apps expect the shared secret in Base32 (the RFC 4648 alphabet A–Z and 2–7) because it is case-insensitive and avoids ambiguous characters, which makes it safe to type by hand and to embed in an otpauth URI. This generator outputs that exact alphabet, so the keys drop straight into authenticator apps and 2FA libraries.
Do the server and the app use the same secret?
Yes — TOTP is a shared-secret scheme: the server stores the secret and the user's authenticator app holds the same secret, and both independently compute the same time-based code. That is why the secret must be generated securely and shared only once (via the QR code) and never exposed afterward.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.