Live RFC 6238 TOTP (6-Digit 30s) & HOTP 2FA Token Generator (2026)

When you scan a 2FA QR code, your phone stores a shared Base32 secret key (K). Every 30 seconds, both your phone and the server independently divide the current Unix epoch timestamp (seconds since Jan 1, 1970 UTC) by 30: C = floor(UnixTime / 30). Because both devices feed the same secret K and 8-byte counter C into HMAC-SHA1, they compute the exact same 6-digit number completely offline.

First, the algorithm looks at the lowest 4 bits of the final byte of the HMAC digest: offset = hmac[19] & 0x0f (giving an index between 0 and 15). Next, it reads 4 consecutive bytes starting at hmac[offset..offset+3], masks off the most significant bit (& 0x7fffffff) to avoid signed/unsigned 32-bit integer ambiguity, and takes the remainder modulo 10^6 (1,000,000), zero-padding to 6 digits.

RFC 4648 Base32 is case-insensitive and intentionally excludes the digits 0, 1, 8, and 9 so humans manually typing a backup key never confuse '0' with 'O', '1' with 'I'/'l', or '8' with 'B'. Every 8 Base32 characters encode 40 bits (5 bytes).

HOTP uses an incrementing event counter (C = 0, 1, 2...) that advances only when the button is pressed and verified, which can become desynchronized if a user presses the hardware token repeatedly without logging in. TOTP simply replaces the event counter with a time-step counter derived from the UTC clock.

TOTP codes are not cryptographically bound to the browser's domain origin or TLS connection. If a user is tricked into typing their 6-digit TOTP code into a real-time Adversary-in-the-Middle (AitM) reverse proxy like Evilginx, the attacker replays the token within the 30-second window. FIDO2/WebAuthn signs the exact origin domain with an asymmetric private key, making phishing relays cryptographically impossible.