When you set up two-factor authentication, you're shown a QR code or a string of letters and numbers. That string is your TOTP secret key — and understanding what it is and how it works will help you use 2FA more securely.
In This Guide
What Is a TOTP Secret Key?
A TOTP (Time-based One-Time Password) secret key is a randomly generated string that is shared exactly once between you (or your authenticator app) and the service you're protecting. It's the foundation of how TOTP-based 2FA works — every 6-digit code you see in your authenticator app is derived from this key.
The key is generated when you first set up 2FA. It's typically presented as a QR code (which encodes it in the otpauth:// URI format) or as a plain base32 string you can type manually. After setup, you never need to see or transmit the key again.
How It Generates Your 2FA Codes
TOTP codes are produced by combining two inputs: the secret key and the current time. Specifically, the current Unix timestamp is divided by 30 to produce a "time window" number. This number is then combined with the secret key using HMAC-SHA1 to produce a hash, and 6 digits are extracted from that hash.
Your authenticator app and the server both perform this calculation independently using the same secret key and the same clock. Because both calculations always produce the same result, the codes match — without ever transmitting the code over a network. This is why TOTP works even with no internet connection.
You can verify this yourself: use the TOTP Secret Key Generator to create a key, then paste it into 2faco.com — you'll see live codes generating every 30 seconds, all in your browser.
What It Looks Like
TOTP secret keys are encoded in base32 — a character set that uses only uppercase letters A–Z and digits 2–7. A typical key looks like: JBSWY3DPEHPK3PXP. Most keys are between 16 and 32 characters long. The minimum recommended length is 16 characters (80 bits of entropy); 32 characters (160 bits) is most common.
Spaces don't affect the key — they're sometimes added in groups of 4 for readability. If you need to enter a key manually, remove all spaces first.
Why You Must Keep It Secret
Anyone who has your TOTP secret key can generate your 2FA codes at any time. This means they can bypass your second factor completely. The secret key should be treated with the same level of care as your password — ideally more, since it's harder to change after the fact.
Never enter your TOTP secret key on any website you don't fully trust. Never share it via email or message. Legitimate services will never ask for it after initial setup. If you suspect a key has been compromised, disable and re-enable 2FA on that account immediately to generate a new key.
How to Generate One Safely
If you're implementing 2FA in your own application and need to generate secret keys for users, use a cryptographically secure random number generator. Our browser-based TOTP Secret Key Generator uses crypto.getRandomValues() — the same API used by TLS — to generate keys that are truly random and never transmitted anywhere.
In code: in Python, use pyotp.random_base32(). In Node.js, use speakeasy.generateSecret() or generate raw bytes with crypto.randomBytes() and encode as base32.
Backing Up Your Secret Key
Your TOTP secret key is the most important thing to save when setting up 2FA. If you lose access to your authenticator app and don't have the key or backup codes, you may be permanently locked out. Write the key down and store it somewhere physically secure — a safe, or with important documents. Some password managers (like 1Password or Bitwarden) support storing TOTP secrets alongside passwords.
See also: 2FA backup codes explained — the other safety net you should always save.
The Anatomy of the otpauth:// URI
When you scan a QR code, your authenticator app is actually reading a URI with the format otpauth://totp/Issuer:account?secret=...&issuer=...&algorithm=SHA1&digits=6&period=30. The secret parameter is the key itself; the remaining parameters are metadata the app uses to label the account and generate codes correctly. Most authenticator apps can import this URI directly — you can paste it in instead of scanning a QR code, which is useful when setting up 2FA on a device without a camera.
If you build your own 2FA flow, the negotiated parameters matter: the app and the server must agree on the algorithm, the number of digits, and the period, or codes will never match. The URI exists precisely to communicate those choices reliably, so always generate it from your stored values rather than hardcoding assumptions.
Common Mistakes with Secret Keys
The classic errors: typing the key with spaces or confusing characters (base32 deliberately omits the characters 0, 1, 8, and 9 to reduce mistakes), storing keys in screenshots or cloud notes that sync across every device, and reusing the same key for multiple accounts — which turns one leak into many. If you suspect a key has been exposed, rotate it immediately by disabling and re-enabling 2FA on that account, which issues a fresh secret and invalidates the old one.
For developers: generate keys only with a cryptographically secure random source, never log keys or QR codes server-side, and encrypt the secret at rest in your database. Treat the TOTP secret as a credential of equal standing to the password — an attacker who holds both can authenticate as the user with no further checks.
Secret Keys vs Backup Codes: What's the Difference?
Both are recovery artifacts issued at setup, but they work completely differently. A secret key is the seed itself: enter it into any TOTP app and you recreate the full code generator forever, with every code the service accepts. Backup codes are one-time tickets: each code signs you in exactly once, then dies. The key gives you a working authenticator; backup codes give you a way past the authenticator.
This distinction drives strategy. The key is the better long-term backup because it never expires and requires no counting — but it is also the riskier thing to store, since whoever holds it holds your 2FA. Backup codes are safer to scatter (each one dies after use) but finite: ten codes, ten emergencies. The best setups use both: the key stored in a password manager for recovery, and backup codes printed for the moments you need access without touching a device.
Moving a Secret Key to a New Device
To move an account between authenticator apps, you have two options. The clean one: log into the service, disable 2FA, re-enable it, and scan the fresh QR code with the new app — this rotates the key, so any old copies die with it. The quick one: export or manually type the existing key into the new app, which keeps the same secret. Manual entry works for any app that offers "enter setup key", and it is exactly how you restore from a key you saved at setup.
Whichever path you choose, verify the new app produces a code the service accepts before you delete the old entry. Keep both apps active side by side for a few logins — most services tolerate two registered authenticators briefly, and some permanently. When you type a key, remove any spaces and enter the letters in uppercase; many apps are case-insensitive, but some importers treat the string literally.
Troubleshooting: Codes Don't Match After Entering the Key
The usual culprit is the clock. TOTP windows are 30 seconds wide, and a device whose time has drifted by more than a few minutes will produce codes the server rejects — fix it by enabling automatic and network-provided time, then try again after the window rolls over. The second most common cause is a parameter mismatch: if the service issues keys for SHA256, SHA512, or an 8-digit code, and your app is configured for SHA1 with 6 digits, nothing will ever match. Most apps let you edit these fields after adding an account; compare them against the otpauth URI parameters shown at setup.
A third cause is copying trouble: pasting an otpauth:// URI where the app expects a bare secret (or the reverse), a trailing space, or a truncated key from a screenshot. If the key came from a photo, type it manually. When in doubt, re-check the service's own "show secret" screen and re-enter it cleanly — and remember that a key that was never actually accepted at setup will still appear in your app while failing at login.
A Secret Key Security Checklist
- Store the key in a password manager, not a cloud note or photo album
- Never paste the key into chat threads, support tickets, or form fields on sites you cannot vouch for
- Rotate the key if it has been photographed, emailed, or entered anywhere suspicious
- Verify the key generates a working code before you close the setup screen
- Keep a printed copy of the key for your most critical account in a physically safe place
Work through the list once when you set up 2FA on a new account, and the "what is this string for" question stops costing you sleep. The secret key is the strongest recovery asset you have — treat it like the password it effectively is.