OTP code generator and validator
Generate TOTP and HOTP codes per RFC 6238 / RFC 4226 (HMAC-SHA1/SHA256/SHA512), see the current, previous and next code with the seconds left, and validate a code you type in.
Runs in your browserEvery computation happens in your browser — your data never leaves this device.
······
Left 30 s
············What this tool does
- Debug two-factor auth locally: paste the Base32 secret and see the current, previous and next code plus the seconds left, without waiting for an app to refresh.
- Diagnose a mismatch with your server: try the same secret under SHA-1 / SHA-256 / SHA-512, 6 or 8 digits and 30 or 60 second steps until the parameters line up.
- Validate a code someone typed: entering the digits compares them against the current time step, and the adjacent steps (±1) are accepted by default, which absorbs small clock drift.
- Work offline: on an internal machine, in a container or anywhere without a phone, compute HOTP/TOTP while the secret stays in the browser.
Example
Input
Mode: HOTP (counter) Secret: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ (Base32) Algorithm: SHA-1 Digits: 6 Counter: 1
Output
Code: 287082
This is the standard RFC 4226 Appendix D test vector (counter 1 → 287082). In TOTP mode the same secret at time step 1 (seconds 30–59) yields 412578, matching the RFC 6238 6-digit output.
Frequently asked questions
Should I pick TOTP or HOTP?
Most authenticator apps (Google Authenticator and similar) use TOTP: the code follows a time step and no counter has to be synchronised. HOTP uses an incrementing counter that advances on each successful verification; hardware tokens and some internal systems still use it, and you need the server to tell you the current counter value.
Do spaces or padding in the secret matter?
Spaces are ignored, trailing = padding is optional and Base32 is case-insensitive. If your server hands out a hex secret, switch the format to Hex and paste it as is. Empty secrets and invalid characters are reported separately.
Why does my server compute a different code?
In order of likelihood: a different algorithm (most services default to SHA-1, some use SHA-256), different digits (6 or 8), a different period (30 or 60 seconds), or clock skew. TOTP depends entirely on time, so a machine that is tens of seconds off produces a completely different code.
Why does validation accept ±1 time step?
It is the window recommended by RFC 6238 to absorb tens of seconds of drift between client and server, so a user entering the previous step right at a boundary is not rejected. The window is fixed at 1, meaning the previous, current and next steps all pass.
Is it safe to type a real secret here?
Codes are computed locally per RFC 4226 / 6238 and the page makes no network requests, so the secret never leaves your browser. It is still sensitive second-factor material, so close the page afterwards and avoid saving it on a shared machine.
Keywords：totphotpotp2fa双重验证动态口令验证码google authenticatorrfc 6238rfc 4226base32