2FA Authenticator

Why your authenticator code is rejected

Most 2FA failures are not mysterious. When an authenticator app and a website disagree about the six digit code, the cause is almost always one of five things: the shared secret was mistyped, the clock on the device running the authenticator is off, the service expects a different digit count or hash than the app is using, the account was enrolled twice and you are reading a stale entry, or the code was copied with a few seconds left on its timer. This page computes the codes itself and then shows you the whole parameter set, so you can tell those five apart instead of guessing.

The secret is the only part that matters. Once two parties hold the same secret and agree on the time window, the six digit code is fully determined by RFC 6238. There is no server call involved, which is why this page can run entirely inside your browser. Your secret is never uploaded, never logged and never leaves the tab, because a tool that asks for your 2FA seed and then phones home is a worse risk than the problem you came here to fix.

Time drift is the reason most people give up. A TOTP code is valid for a window of thirty seconds, and most services will also accept the previous window, giving you about sixty seconds of tolerance in total. If your phone clock is ninety seconds fast, every code you copy is already stale by the time it reaches the server, and no amount of retyping helps. The drift table below solves this the only way it can be solved: by printing the code for a range of clock offsets so you can match your authenticator against one of them and read off how far off your device actually is.

The parameter table matters for a different reason. An otpauth URI carries far more than the secret. It carries the algorithm, which is SHA-1 for almost every service in the world but SHA-256 or SHA-512 for a handful. It carries the digit count, which is six almost everywhere and eight for a few banking and enterprise systems. It carries the period, which is thirty seconds unless the service chose otherwise. When an app is enrolled manually from a typed secret, these three defaults are assumed silently, and that is exactly where mismatches creep in.

Issuer mismatch is the failure nobody warns you about. The specification says that the issuer inside the account label and the issuer parameter should agree, and when they do not, an authenticator app is allowed to trust whichever one it likes. A link whose label reads GitHub but whose issuer parameter reads something else is the shape a phishing page produces, and it is also the shape some older enrolment flows produce by accident. Either way you want to know before you scan it.

Counter based codes, usually called HOTP, use a number that goes up by one per login instead of the clock. Some hardware tokens and a few older enterprise systems still work this way. Most web tools ignore them, which leaves anyone holding a counter based token unable to check their code anywhere at all. This page implements both so the same tool covers the whole family.

The built in self test runs the published test vectors from RFC 6238 against the exact code that produces the code on your screen. If every vector matches, the implementation is correct and any remaining disagreement is on the device side. If a vector fails, you know the problem is here rather than in your phone, and you should not waste another ten minutes retyping codes.

How to use it

1. Drop in the QR code screenshot the service showed you, or paste the otpauth link or the Base32 setup key.
2. Read the setup parameters. Compare the issuer, algorithm, digits and period against what the service told you.
3. Type the displayed code into the login form. The bar shows how long it stays valid.
4. If it is rejected, open the clock drift diagnosis and match your authenticator against the offsets.

Nothing is transmitted. There is no server behind this page.

Frequently asked questions

Can an AI chatbot generate my 2FA code?

No, and it should not be asked to. Generating a code requires your Base32 secret and an exact match between your clock and the server's. A language model cannot compute either, and pasting a 2FA seed into a chat window permanently hands your second factor to whoever stores that conversation. This page computes locally for the same reason.

Why does my code work on one site and not another?

Two accounts enrolled from the same secret, or two accounts with different digit counts and algorithms. Both mistakes happen silently during manual enrolment, because the setup key alone carries none of that information. The setup parameters panel shows what this entry actually uses.

What does an issuer mismatch mean?

The account label and the issuer parameter disagree, for example a label of GitHub:alice with an issuer of something else. RFC 4226 section 5.2 says the two should match. When they do not, authenticator apps differ in which one they display, which makes a phishing QR and a genuine one look identical in the app. Treat any mismatch as a reason to verify the domain before logging in.

How far can my device clock be off before codes fail?

With the default 30 second period and a server that accepts one step of clock drift, you have roughly 60 seconds of tolerance. Outside that window every code is stale. Most services expose their tolerance, and a handful accept nothing at all, which is why a phone with a manual date can lock you out completely.

Is it safe to paste my setup key here?

The calculation runs in this page using the browser's Web Crypto API. No network request carries the secret, and nothing is stored. The risk of pasting a secret into any other web tool is that the secret exists on someone else's server, where it can be logged, cached or breached. Do not reuse a setup key you have pasted elsewhere, and rotate this account's 2FA if you are unsure where you have typed it.

What is HOTP and when do I need it?

HOTP is the counter based scheme in RFC 4226. Instead of deriving the code from the clock, it derives it from a number that increases by one each time you use the token. You will meet it on older hardware tokens, some enterprise single sign on systems, and anything that asks you to press the button before reading the code.

My secret is not valid Base32, what now?

Strip the spaces and hyphens first, since setup keys are usually printed in groups. After that every remaining character has to come from A to Z or 2 to 7. Zeros and ones are the usual mistakes: an O mistyped as 0, or an I mistyped as 1, and they are invisible in most fonts. The decoder names the exact offending characters rather than failing silently.

Does this replace my authenticator app?

No. An app stores your seeds encrypted on your device and works with no browser at all. Use this page to check a code, decode a link you do not trust, or recover a setup key you stored somewhere safe. Enrolling new accounts is best done in a real authenticator.