Introduction
Your bank, GitHub, and Google Authenticator all use the same 30-second rotating code algorithm. TOTP — Time-based One-Time Password — is defined in RFC 6238 and generates a short numeric code from a shared secret and the current Unix timestamp. Once the code expires, it is mathematically useless. This tool generates and verifies TOTP codes from any Base32 secret key, letting you test authenticator app integrations, debug 2FA enrollment flows, or understand exactly how the algorithm works — directly in your browser.
What this tool does
- Generates TOTP codes from a Base32 shared secret using the RFC 6238 algorithm with configurable digit count (6 or 8) and period (30 or 60 seconds).
- Displays a live countdown timer showing the remaining validity window for the current code.
- Implements HOTP (HMAC-based One-Time Password, RFC 4226) for counter-based OTP generation.
- Shows the rolling code update in real time without requiring a page refresh.
- Runs entirely client-side — your secret key never leaves the browser.
How this tool works
The TOTP generator takes your Base32 secret and the current Unix timestamp, divides the timestamp by the configured period (default 30 seconds), and floors the result to get the current time step T. It then computes HMAC-SHA1(secret, T) — a 20-byte hash — and applies dynamic truncation: it reads the last nibble of the hash as an offset, takes 4 bytes starting at that offset, masks the top bit, and reduces modulo 10^digits to get the numeric code.
The live countdown bar tracks the current position within the 30-second window. When the window expires, the time step increments by 1, a new HMAC is computed, and a new code appears. HOTP mode works identically except the counter value T is manually incremented rather than time-derived, which is suitable for hardware tokens without a real-time clock.
How the cipher or encoding works
HOTP was published as RFC 4226 in 2005 by the Initiative for Open Authentication (OATH). TOTP (RFC 6238, 2011) extended HOTP by deriving the counter from the current UTC time, solving the synchronisation problem inherent in pure counter-based OTPs.
The algorithm has three steps. First, compute HMAC-SHA1 of the time counter using the shared secret. HMAC is defined in RFC 2104 and produces a deterministic 160-bit output from any key and message. Second, apply dynamic truncation: this was designed to extract a 31-bit number from the 160-bit HMAC using a deterministic but non-trivial offset, reducing the attack surface of simple modular reduction. Third, reduce that 31-bit number modulo 10^6 to get a 6-digit decimal code.
The 30-second window is a deliberate usability tradeoff. A 1-second window is too strict for clock skew between devices; a 60-second window increases the attack surface for credential interception. RFC 6238 recommends server implementations accept codes from the previous and next windows (±1 step) to tolerate clock drift of up to ±30 seconds.
Base32 encoding (RFC 4648 §6) is used for the secret key because it avoids ambiguous characters (0/O, 1/I) and is case-insensitive, making it suitable for manual entry or QR code scanning by authenticator apps like Google Authenticator, Authy, and 1Password.
How to use this tool
- Enter your Base32 secret key in the 'Secret' field. This is typically provided as a QR code or plain string during 2FA enrollment.
- Select the number of digits (6 is standard; some enterprise services use 8).
- Select the period (30 seconds is universal; some services use 60).
- Click 'Generate'. The current TOTP code appears along with the countdown to the next rotation.
- For HOTP mode, switch tabs and enter an integer counter value to generate the corresponding one-time code.
Real-world examples
Testing a 2FA enrollment flow in a Node.js app
A developer integrates TOTP into their authentication service using the `speakeasy` npm library. During QA, they enroll a test user, copy the generated Base32 secret, and paste it into this tool. They compare the code shown here against what their app accepts. If the codes match at the same second, the enrollment and HMAC key derivation are working correctly. If not, the most common bug is a Base32 decoding error — the library may expect uppercase without padding ("=") stripped.
Clock skew debugging
A user reports their TOTP codes are "always rejected." The developer asks them to check their device clock — NTP sync is off by 95 seconds. Using this tool, the developer generates codes for the current time step and for the two adjacent steps (T-1 and T+1). The server's ±1 window toleration covers 30 seconds of drift. At 95 seconds, the user falls outside the accepted window and every code fails. The fix: enable NTP auto-sync, not a code change.
Understanding HOTP for hardware tokens
A security engineer evaluates a batch of hardware OTP tokens with no RTC (real-time clock). The vendor provides the HOTP counter-based algorithm with a factory-set counter starting at 0. The engineer enters the token's Base32 secret and counter 0 into the HOTP tab, confirms the expected 6-digit code, then tests counter 1 and counter 2. Because HOTP uses a persistent counter rather than time, the server must track the last valid counter per user and implement look-ahead (typically up to counter+50) to handle missed button presses.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| TOTP (RFC 6238, time-based) | HMAC-SHA1 per 30s window | Authenticator apps (Google Authenticator, Authy, 1Password) |
| HOTP (RFC 4226, counter-based) | HMAC-SHA1 per counter increment | Hardware tokens without a real-time clock |
| SMS OTP | Server-generated random | Consumer account recovery; weaker against SIM swap |
| WebAuthn / FIDO2 passkey | Asymmetric public-key challenge | Phishing-resistant 2FA; replacing TOTP in high-security flows |
Limitations or considerations
TOTP codes are phishing-vulnerable: a man-in-the-middle attack that relays the code in real time can reuse it within the 30-second window. This is why FIDO2/WebAuthn is preferred for high-value accounts. HMAC-SHA1 is the default algorithm and is specified by RFC 6238, but SHA-1 is no longer collision-resistant. Some authenticator apps support HMAC-SHA256 and HMAC-SHA512 variants, though most services still use SHA-1 for compatibility. This tool's implementation uses a simplified HMAC for demonstration; production deployments must use a vetted cryptographic library such as `crypto` (Node.js built-in) or `WebCrypto` (browser standard).
Frequently asked questions
Conclusion
TOTP is the de facto standard for app-based two-factor authentication, specified in RFC 6238 and implemented by every major authenticator app. This tool lets you generate and inspect TOTP and HOTP codes from any shared secret, making it useful for integration testing, debugging clock skew, and understanding the underlying algorithm. For phishing-resistant 2FA in production, evaluate FIDO2 passkeys as an alternative where the threat model warrants it.