How do I test a 2FA code without locking myself out?

Generate the code from your saved key and compare it with the one your authenticator app shows for the same account. If the digits match, the key is good — and you have learned it without submitting anything to the service, which is what makes repeated failed attempts a risk in the first place.

What does it mean when two authenticators show different codes?

Something other than the secret differs. In order of likelihood: one device has a clock that is off, the service uses a non-default algorithm such as SHA-512, or the period or digit count does not match. The secret itself either loads or does not — a wrong secret produces wrong codes every time, not sometimes.

Can I test a key before enrolling it?

Yes, and it is the best moment to do it. While the QR code is still on screen the service has not committed you to anything. Paste the key, confirm the code it produces matches what your app shows, then submit that code to finish enrollment knowing both copies agree.

How do I know my device clock is the problem?

The panel shows the seconds remaining in the current step against your device clock. If a service consistently rejects codes that look right, compare your clock against a known-good source — a phone with automatic time sync, or any time server page — and turn automatic sync back on. About thirty seconds of error is enough to break TOTP.

Is there a test secret I can use?

Use the RFC 6238 vector: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, which is the ASCII string 12345678901234567890 in Base32. With SHA-1, 8 digits and a 30-second step, Unix time 59 must produce 94287082. It is a published test value, so it is safe to paste anywhere — never test with a real account secret on a machine you do not control.

Does testing here tell the service anything?

No. Generating a code is arithmetic on your device, with no request to the service and nothing to rate-limit. That is exactly why testing here beats guessing at the login screen, where repeated failures can trigger a lockout or a fraud review.

2FA Tester — Check a Setup Key, a Clock and a Backup Before You Need Them

The worst time to discover a setup key is wrong, a backup is stale or a clock has drifted is at a login screen you cannot get past. Every check below runs on this page against your own device, submits nothing to the account, and cannot trigger a lockout.

Three tests worth running

Does the saved key still match? Paste the key you keep in a password manager and compare its digits with your authenticator app for the same account, inside one 30-second window. Agreement means your backup is real. Disagreement means the account was re-enrolled at some point and the copy you saved is dead — which you would otherwise find out only after losing the phone.
Is the clock honest? The panel counts down the current step against your device clock. A machine that has been asleep, dual-booted or set by hand can sit tens of seconds out without anything looking wrong, and TOTP breaks at roughly thirty.
Do the parameters match the service? If the codes are wrong and the clock is right, open Advanced and check algorithm, digits and period against what the service issued. Most apps silently assume SHA-1, six digits, thirty seconds, and never tell you when the key said otherwise.

Testing at enrollment, which is the cheapest moment

While the QR code is still on screen the service has not finished enrolling you, and nothing is at stake yet. Save the text key, paste it here, and confirm the digits match the app you intend to rely on before you submit the confirmation code. Two copies that agree at that moment is the whole point of keeping a key at all.

Do this once per account

A key that has been verified against the app is a backup. A key sitting in a password manager that nobody ever checked is an assumption — and the lost-phone guide exists because assumptions fail at exactly the wrong moment.

Reading a failed test

Codes differ every window. A parameter mismatch or a different secret. Compare against the original otpauth:// link if you still have it, since it carries the parameters the service actually set.
Codes match here but the service rejects them. Clock drift on the device you are logging in from, or a code submitted after its window closed. Sync the clock and submit a fresh code early in its 30 seconds.
The key will not load at all. It is not valid Base32 — a transcription error, or a hex secret from an enterprise system that needs converting first.
Everything matches and login still fails. Then 2FA is not what is failing. Check whether the service wants a backup code, a device approval, or a different account than the one you are testing.

If you are testing an implementation rather than an account

Use the published RFC 6238 vector rather than a live secret: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, with SHA-1, eight digits and a 30-second step, must produce 94287082 at Unix time 59 and 89005924 at 1234567890. The whole table, including the SHA-256 and SHA-512 rows, is on the TOTP explainer, and the generator page exposes every parameter you need to reproduce them.

Two things catch most implementations: the leading zero in a code is significant, and the SHA-256 and SHA-512 vectors use longer secrets than the SHA-1 one rather than the same twenty bytes.

Questions

How do I test a 2FA code without locking myself out?: Generate the code from your saved key and compare it with the one your authenticator app shows for the same account. If the digits match, the key is good — and you have learned it without submitting anything to the service, which is what makes repeated failed attempts a risk in the first place.
What does it mean when two authenticators show different codes?: Something other than the secret differs. In order of likelihood: one device has a clock that is off, the service uses a non-default algorithm such as SHA-512, or the period or digit count does not match. The secret itself either loads or does not — a wrong secret produces wrong codes every time, not sometimes.
Can I test a key before enrolling it?: Yes, and it is the best moment to do it. While the QR code is still on screen the service has not committed you to anything. Paste the key, confirm the code it produces matches what your app shows, then submit that code to finish enrollment knowing both copies agree.
How do I know my device clock is the problem?: The panel shows the seconds remaining in the current step against your device clock. If a service consistently rejects codes that look right, compare your clock against a known-good source — a phone with automatic time sync, or any time server page — and turn automatic sync back on. About thirty seconds of error is enough to break TOTP.
Is there a test secret I can use?: Use the RFC 6238 vector: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, which is the ASCII string 12345678901234567890 in Base32. With SHA-1, 8 digits and a 30-second step, Unix time 59 must produce 94287082. It is a published test value, so it is safe to paste anywhere — never test with a real account secret on a machine you do not control.
Does testing here tell the service anything?: No. Generating a code is arithmetic on your device, with no request to the service and nothing to rate-limit. That is exactly why testing here beats guessing at the login screen, where repeated failures can trigger a lockout or a fraud review.

2FA tester

Three tests worth running

Testing at enrollment, which is the cheapest moment

Reading a failed test

If you are testing an implementation rather than an account

Questions

Next