HOTP counter-based code generator
Generate RFC 4226 counter-based one-time passwords, step the counter by hand, and resynchronise a drifted token with a look-ahead check.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
An unsigned 64-bit integer. Both sides must agree on it.
What an authenticator app stores. 160 bits (32 characters) is the RFC 4226 recommendation.
Shown as the account provider.
Usually an email or username.
Google Authenticator and most hardware tokens only implement SHA1.
Six is near-universal.
otpauth://hotp/onthisdevice:demo%40example.com?secret=&issuer=onthisdevice&algorithm=SHA1&digits=6&counter=0The QR image is drawn on this page from the URI above. It is never uploaded, which matters more here than anywhere else on the site: this string is the entire second factor.
Counter-based, not time-based
HOTP is the original one-time-password algorithm, standardised as RFC 4226 in 2005. It is identical to TOTP in every respect but one: the counter that goes into the HMAC is a number that advances when a code is generated, rather than a value derived from the clock.
That single difference changes the operational picture completely — no clock to keep in sync, no expiry, and a new failure mode of its own.
HOTP versus TOTP
| HOTP (RFC 4226) | TOTP (RFC 6238) | |
|---|---|---|
| Counter source | An event counter | Unix time ÷ step |
| Code lifetime | Until it is used | Typically 30 seconds |
| Needs a clock | No | Yes, on both sides |
| Main failure mode | Counter drift | Clock skew |
| Server state | Must persist the counter | Stateless beyond the secret |
| Typical use | Hardware tokens with no battery, OATH keys | Authenticator apps, nearly all web 2FA |
Counter drift, and how servers cope
Every time a user presses the button on a token and does not submit the code, the token's counter moves forward and the server's does not. After enough idle presses the two are far apart and every code is rejected.
Servers therefore accept a look-ahead window — typically the next 3 to 10 counters — and when a submitted code matches one of them, they resynchronise by setting their counter past the match. The verifier above does exactly this: it checks ten steps ahead and tells you the value the server should be set to. What a server must never do is accept a counter behind its own, because that would allow a captured code to be replayed.
Which is more secure?
Neither, straightforwardly. An HOTP code stays valid until used, so one intercepted over the shoulder or by phishing keeps working — that is a real weakness. A TOTP code expires in under a minute, but TOTP fails entirely if a device's clock is wrong, and a sizeable fraction of support tickets for 2FA are exactly that. Most services choose TOTP because clock sync is cheap on a phone and the short window is worth having.
Where you still meet HOTP
- OATH-HOTP hardware tokens — a keyfob with a single button and no clock.
- YubiKey OATH-HOTP slots, still used in enterprise deployments.
- Bank card readers that generate a code per transaction.
- Paper backup lists, where each code is the next counter value in sequence.
The URI for enrollment
An HOTP provisioning URI carries counter in place of period:
otpauth://hotp/Example:alice?secret=JBSWY3DPEHPK3PXP&counter=0&digits=6
Fewer authenticator apps support the hotp type than totp, and some
silently import it as TOTP — which then produces codes that never match anything. Test the
first code after enrolling.
Computed here, stored nowhere
The HMAC runs in WebCrypto in this tab, and neither the secret nor the counter is persisted: refresh the page and both are gone. Use this to test a token, work out where a counter ended up, or validate an integration — not as a place to keep a credential.
Questions
How is HOTP different from TOTP?
The counter. HOTP advances only when a code is generated; TOTP derives the counter from the clock. That makes HOTP suitable for hardware with no battery-backed clock, and it means codes stay valid until used.
What is counter drift and how do I fix it?
If a token generates codes that are never submitted, its counter runs ahead of the server. Servers therefore accept a window of the next several counters and resynchronise on a hit — this page checks ten steps ahead and tells you the value to set.
Which is more secure?
Different trade-offs. A TOTP code expires in under a minute; an HOTP code stays valid until used, so an intercepted one keeps working. HOTP avoids clock-sync failures entirely. Most services choose TOTP.
Can I use an existing YubiKey OATH secret?
Yes, if you hold the Base32 secret — paste it and set the counter. You cannot read the secret back out of the key itself; that is the point of the hardware.