A TOTP and HOTP generator for testing two-factor authentication
This OTP generator produces the same six- or eight-digit one-time codes as an authenticator app. It implements HOTP (RFC 4226, counter-based) and TOTP (RFC 6238, time-based) with HMAC-SHA-1, SHA-256 or SHA-512, shows the live code with a countdown ring, the codes on either side for clock drift, an otpauth:// link and a QR code you can scan into an app — and it checks codes that someone typed.
It is aimed at developers adding 2FA to a login, testers who need a code without reaching for a phone, and anyone curious about what their authenticator is doing. A random 160-bit secret is created when the page opens; you can also paste a Base32, hex or plain-text secret, or import an existing otpauth link.
Everything is calculated with your browser’s Web Crypto API; nothing is stored or sent. Only the QR code library (qrcode-generator, MIT licence) is loaded from a CDN.
How to use the OTP Generator (TOTP & HOTP)
- Choose TOTP for codes that change every 30 or 60 seconds, or HOTP for codes tied to a counter.
- Keep the random secret or paste your own into Secret key, and set Secret format if it is hex or plain text rather than Base32.
- Set the Algorithm, Digits and Time step (or Counter) to match the service. The code and its countdown ring update instantly.
- Fill in Issuer and Account name, then scan the QR code with an authenticator app or copy the otpauth link.
- Type a code into Verify a code to see whether it matches the current step or a neighbouring one within the window you choose.
OTP Generator (TOTP & HOTP) features
Both RFC algorithms
HOTP with dynamic truncation exactly as RFC 4226 describes, and TOTP per RFC 6238 with HMAC-SHA-1, SHA-256 and SHA-512, 6–8 digits and 30 or 60-second steps.
Checked against the RFCs
The page’s self-test reproduces all ten HOTP values of RFC 4226 Appendix D and all eighteen TOTP test vectors of RFC 6238 Appendix B.
Clock-drift helpers
Previous and upcoming codes with their start times, a fixed-time mode for reproducing a code from a log, and a verifier with a ±0, ±1 or ±2 step window.
QR code and otpauth link
Builds a standard Key URI with issuer, algorithm, digits and period or counter, draws it as a QR code you can download, and imports existing links.
Secret checks
Explains invalid Base32 characters and truncated secrets, and warns about keys shorter than 128 bits.
How a TOTP code is calculated
Worked example from RFC 6238: the ASCII secret 12345678901234567890 is GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ in Base32. At Unix time 59 with a 30-second step, T = 1 and the 8-digit SHA-1 code is 94287082; with six digits it is 287082, the same as HOTP counter 1 in RFC 4226. Tick “Use a fixed time”, enter 59 and the generator shows exactly these values.
- Decode the shared secret from Base32 into bytes. Base32 (RFC 4648) uses the letters A–Z and digits 2–7, so it survives being read aloud or typed.
- For TOTP, take the Unix time in seconds, divide by the period and round down: that integer T is the moving factor. HOTP uses the counter instead.
- Compute HMAC-SHA-1 (or SHA-256/512) of T written as an 8-byte big-endian number, keyed with the secret.
- Dynamic truncation: the low 4 bits of the last byte give an offset; read four bytes from there, clear the top bit and take the result modulo 10digits.
Settings and authenticator app support
| Setting | Most compatible | Notes |
|---|---|---|
| Algorithm | SHA-1 | HMAC-SHA-1 is still secure for OTPs; SHA-256/512 are not supported by every app |
| Digits | 6 | 8 digits reduce guessing odds but some apps display only 6 |
| Period | 30 seconds | 60 s gives more time to type but a longer replay window |
| Secret length | 160 bits (32 Base32 characters) | RFC 4226 requires at least 128 bits |
| Server window | ±1 step | Accepts codes up to about 30 s early or late |
Building 2FA on a server? Get these details right
- Store secrets encrypted and generate them with a cryptographic random generator — never derive them from a user’s password or ID.
- Reject replays. Remember the last accepted time step (or counter) for each user and refuse a code from the same or an earlier step.
- Rate-limit attempts. A six-digit code has one million possibilities; without lockouts an attacker can brute-force it within its window.
- Keep the window small — ±1 step is the usual balance — and keep server clocks synchronised with NTP.
- Offer recovery codes when enrolling, since users lose phones. A Password Generator or Random String Generator can create them.
- Times in TOTP are Unix seconds in UTC; the Unix Timestamp Converter helps when matching log entries.
OTP Generator (TOTP & HOTP) FAQ
Is it safe to use an online OTP generator?
This one runs entirely in your browser and never stores or transmits the secret. Still, a secret typed into any web page can be exposed by a malicious browser extension or a screen share, so keep the secrets of important accounts in an authenticator app or password manager.
Why does my authenticator show a different code?
Usually one of four things differs: the secret (a mistyped character), the algorithm, the number of digits or the period. Some apps ignore SHA-256, 8 digits or 60 seconds in a QR code and fall back to the defaults. If everything matches, compare the device clocks — TOTP needs them within about 30 seconds.
What is the difference between TOTP and HOTP?
HOTP codes depend on a counter that increases each time a code is generated, so they stay valid until used. TOTP replaces the counter with the current 30 or 60-second time step, so each code expires on its own. TOTP is what authenticator apps use for almost every website.
How long should a TOTP secret be?
RFC 4226 requires at least 128 bits and recommends 160 bits, which is 32 Base32 characters. The random secret button generates 160 bits with crypto.getRandomValues.
Can this generator create a QR code for Google Authenticator or Microsoft Authenticator?
Yes. It builds a standard otpauth:// link with the issuer and account name and draws it as a QR code that common authenticator apps can scan. After scanning, confirm that the app’s code matches the one shown here.
What does “window ±1” mean when verifying?
The verifier also accepts the code from one step before or after the current one. That tolerates a slow typist or a clock that is a little off. For HOTP, an earlier counter is reported as a replay that a server should refuse.