The Setup Key Is the Real Secret
When a website shows you a 2FA QR code, it is showing you a text string dressed up for cameras. That string, called the setup key, secret key, manual code, or seed depending on the service, is the actual cryptographic secret your six digit codes grow from. The QR exists purely so you do not have to type the string yourself. When scanning fails, is physically impossible because you are setting up 2FA on the same phone whose camera you would need, or you simply prefer typing, manual entry produces an identical, equally secure result.
Finding the "Enter This Text Code Instead" Link
Next to every setup QR sits a small link, and the wording varies by service even though the function never does:
- "Can't scan the code?"
- "Enter this text code instead"
- "Setup key", "Manual entry", or "Show secret"
Click it and the site reveals something that looks like JBSW Y3DP EHPK 3PXP. That is Base32, an alphabet of A through Z plus 2 through 7, deliberately chosen because it avoids characters humans confuse with each other. The full design story, including why 0, 1, 8, and 9 do not appear at all, is in our Base32 explainer.
The Formatting Gotchas Before You Type Anything
- Spaces are cosmetic. The four-character groupings you see on screen exist purely to help human eyes track position while reading. Strip them out, or leave them in: every authenticator app ignores whitespace inside the key field automatically.
- Case is usually, but not always, forgiving. Base32 as a standard is uppercase only, and most sites display the key in uppercase already. Most apps will silently uppercase whatever you type or paste. A small number of stricter implementations do not, so if a code that should work is rejected, retype the key in the exact case the website showed it, uppercase included.
- Trailing padding characters. Occasionally a key ends in one or more equals signs used as Base32 padding. Include them if the site shows them; some apps need the padding to compute correctly, others strip it themselves. When in doubt, copy the entire displayed string exactly rather than retyping it.
Entering the Key in Your App
Every authenticator asks for the same two or three pieces of information: an issuer or account label, the secret itself, and occasionally the type of key.
Google Authenticator
- Tap the plus button, then "Enter a setup key".
- Account name: type something you will recognize months from now, such as "GitHub: yourname" rather than just "GitHub".
- Your key: paste or type the secret.
- Type of key: choose "Time based", the default for virtually every modern service. Counter based is the rare HOTP variant, covered in our TOTP vs HOTP post.
- Tap Add, and a six digit code starts ticking immediately.
Authy, Microsoft Authenticator, 2FAS, Aegis
The concept is identical with slightly different labels. Look for "Enter key manually", "Add account, then Other", or a small keyboard icon on the scanner screen itself. All of them ask for the same label-plus-secret pair described above.
Password Managers With Built-In TOTP (Bitwarden, 1Password)
Edit the relevant login entry and paste the secret into the TOTP, or one-time password, field. The manager then generates and autofills the code alongside the password itself, so both pieces of the login live in one place.
Manually Specifying the Issuer and Account Labels
Most apps infer a sensible label automatically from context, but a handful of stricter setups, and any time you build the entry entirely from a manual otpauth link, want the issuer and account name specified explicitly. The underlying otpauth URI format is otpauth://totp/Issuer:account@example.com?secret=KEY&issuer=Issuer. The label before the colon is the account name shown inside the app; the issuer parameter is what many apps use to show a logo or group entries by service. If an app's manual entry screen exposes separate "issuer" and "account name" fields rather than one combined label, put the service name (GitHub, Google, your bank) in issuer, and your username or email in account name. Getting this right matters mainly for organization: with dozens of entries in one app, a consistent Issuer: account pattern is the difference between finding the right code in two seconds and scrolling through an unlabeled list under pressure.
Confirming the Handshake on the Website
Type the current six digit code from your app back into the site's verification box. This step proves the secret transferred correctly; only after it succeeds does the website actually activate 2FA on your account. If the code is rejected here, work through the typo traps below before assuming anything else is wrong.
Self-Verify Before You Trust It Live
Do not wait for a real login attempt to discover the key was mistyped. Before finishing setup, or any time you are unsure an entry took correctly, paste the exact same secret into our browser TOTP generator and let it compute a code independently of your phone. If the number on screen matches the number in your authenticator app at the same moment, your entry is byte-for-byte correct, and any remaining rejection from the website is a clock problem on the site's end or yours, not a typing mistake. This ten-second cross-check catches the single most common manual entry failure before it becomes a locked account.
The Typo Traps When Confirmation Fails
- 0 versus O, and 1 versus I or l. Base32 contains no zeros and no ones at all. If you typed a 0 or a 1 anywhere, it was actually an O or an I or an L on the original screen. This single fact resolves the majority of manual entry failures on its own.
- 8 and 9 do not exist either. The digit range in Base32 runs 2 through 7 only, nothing else.
- Missing characters. Keys are commonly 16 or 32 characters long once you strip the spaces. Count what you typed against what the site displayed.
- Autocorrect sabotage. Phone keyboards love "fixing" random-looking strings into real words. Paste instead of typing wherever the field allows it, and disable autocorrect for that field if your phone allows per-field settings.
- It's the clock, not the key. If the self-verify step above showed a match, the rejection is a device clock issue rather than a bad secret. The two-minute fix is in our time sync guide.
Why the Setup Key Is Worth Saving Permanently
The underrated part of manual entry is that the key IS your 2FA for that account, forever, independent of any single app or phone. Stored safely offline, it lets you regenerate codes in any app on any device without ever contacting support, enroll two devices at once by entering the same key in both, and skip account recovery drama entirely if a phone is lost or replaced. Treat it exactly like a password: written on the same sheet as your backup codes, using the storage system in our backup codes guide, or saved inside your password manager's secure notes. Never in a plain text file sitting on your desktop labeled "2fa keys".
Frequently Asked Questions
Is manual entry less secure than scanning the QR?
No, the security is identical: same secret, different delivery mechanism. The only added risk during manual entry is a shoulder surfer reading the displayed key off your screen, a risk that applies equally to someone photographing the QR code.
The site only offers a QR, with no manual entry option visible. Am I stuck?
Rarely, and it is still solvable. Screenshot the QR and decode it with our QR decoder. The revealed otpauth link contains secret=YOURKEY in plain text, which you can then type in manually. Delete the screenshot once you have the key.
Can I turn my manual key back into a scannable QR code?
Yes. Build the otpauth URI in the format shown above and paste it into our QR generator to produce a fresh scannable code, useful for enrolling a second device without retyping anything. The URI's full anatomy is covered in our otpauth explainer.
Does the account name label actually matter to security?
No, it only matters to you. It is purely a label for finding the right entry later; the secret itself does all the cryptographic work. Use a consistent naming pattern, such as Service: username, so a list of dozens of entries stays navigable instead of becoming a wall of identical-looking icons.
What is the difference between "time based" and "counter based" when the app asks?
Time based, or TOTP, is the standard virtually every modern service uses: codes rotate automatically every 30 seconds based on the clock. Pick it unless a service explicitly says otherwise. Counter based, or HOTP, advances a code only when it is actually used rather than on a timer, and mostly survives today in older hardware tokens.
