TOTP / HOTP Codes

Features

• TOTP and HOTP per RFC 6238 / RFC 4226, passing every official test vector in both RFCs
• ⚠️ The first line of the page warns against pasting a secret you use — a TOTP secret is the whole second factor
• SHA-1, SHA-256 or SHA-512 (SHA-1 is what nearly every service defaults to)
• Adjustable period and digit count (30 seconds and 6 digits by default, matching the usual apps)
• Shows how many seconds are left in the window and the current counter value
• Lists codes for neighbouring windows, so you can see how far a device clock has drifted
• HOTP mode takes an explicit counter, handy for checking against the RFC vectors
• Secrets may be lower case, space or hyphen separated, or padded; a secret containing 0, 1, 8 or 9 is reported as an error rather than guessed at

How to use

1. ⚠️ Use a test account’s secret, not one you rely on
2. Paste the Base32 secret
3. Match the algorithm, period and digits (most services: SHA-1, 30 seconds, 6 digits)
4. The six digits should match your authenticator app exactly

FAQ

Why does this differ from my authenticator app?

In order of likelihood: clock drift — TOTP depends entirely on both clocks agreeing, and a device off by more than 30 seconds lands in a neighbouring window, so turn on the neighbouring windows and see whether your app’s code appears there; mismatched parameters — algorithm (SHA-1 / 256 / 512), period (30 or 60 seconds) and digits (6 or 8) all change the result; a mistyped secret — secrets contain only A–Z and 2–7, and a handwritten one easily turns 0 into O or 1 into I, which this tool rejects outright rather than guess around.

What is the difference between TOTP and HOTP?

Only where the counter comes from. HOTP uses a counter both sides increment, one per use — but once client and server fall out of sync they never match again, and every press that fails to log in still burns a counter value. TOTP uses time as the counter (current time divided by the period), so as long as the clocks roughly agree no state has to be synchronised. The cost is a 30-second window and a hard dependency on accurate clocks.

Which is worse to leak — the secret or a code?

The secret. A code expires in 30 seconds and is useless without your username and password as well. The secret mints valid codes forever — whoever holds it can sign in at any time and nothing looks unusual on your side. So a leaked secret is the second factor failing entirely, while a leaked code affects only those 30 seconds.

Can this verify that a code is correct?

No, and it should not. Verification means submitting a candidate to a server, which is an online act this static site does not perform. What it answers is “what does this secret produce right now” — compare that against your own authenticator app, and if they agree, the secret and the parameters are both right.