How TOTP Works and Why This Generator Is for Testing
A TOTP code generator produces the same six-digit rotating codes that authenticator apps like Google Authenticator or Authy show when you set up two-factor authentication on an account. TOTP stands for Time-based One-Time Password, defined in RFC 6238, and it is the mechanism behind that familiar enter-the-6-digit-code screen during login. This tool exists for developers testing a 2FA integration, sysadmins debugging why a code will not accept, and anyone who wants to confirm their own secret key produces the expected code before relying on it, without needing a phone in hand. It is explicitly not meant to replace an authenticator app for day-to-day logins; treat it as a testing and verification instrument for setups you already own.
The algorithm starts from a shared secret, typically given as a Base32 string, which gets decoded into raw bytes. A counter value is computed as the current Unix time divided by the period (usually 30 seconds) rounded down, then packed into an 8-byte big-endian buffer. That counter is HMAC-signed using the secret as the key, with SHA-1 as the RFC 6238 default, though SHA-256 and SHA-512 are also supported since some services use them. The resulting HMAC output undergoes dynamic truncation: the low four bits of the last byte become an offset, four bytes are read starting at that offset, the top bit is masked off to keep the number positive, and the resulting 31-bit integer is taken modulo ten to the power of the digit count, then padded with leading zeros to the requested length.
RFC 6238's own Appendix B test vectors use the ASCII secret 12345678901234567890 with SHA-1 and a 30-second period. At Unix time 59, which is inside the very first 30-second window after the epoch, the algorithm produces the eight-digit code 94287082. At Unix time 1111111109 it produces 07081804, and one second later at 1111111111 it produces a different code, 14050471, showing the code changes the instant a new 30-second window begins. At 1234567890 the code is 89005924, and at 2000000000 it is 69279037. This tool reproduces every one of those five values exactly, which is the standard way to confirm any TOTP implementation, including an authenticator app itself, is computing codes correctly.
A developer wiring up TOTP-based 2FA for a new signup flow can generate a test secret, feed it into both this tool and their own backend verification code, and confirm the two produce matching digits before ever touching a real phone or QR code. Someone migrating between password managers or authenticator apps can paste an otpauth URI extracted from a QR code to double-check the secret, issuer, digit count, and period were captured correctly during migration, catching a misconfigured period or digit count before it locks them out. IT support staff troubleshooting a my-code-never-works ticket can paste a user's secret with consent, in a secure session, and watch whether the previous, current, and next codes line up with what the user reports seeing, which usually reveals a clock-drift issue rather than a broken secret.
The most common real-world TOTP failure is clock drift: if the device generating codes and the server verifying them disagree on the time by more than roughly one period, codes will consistently fail even though the secret is correct, which is why this tool shows the previous and next code alongside the current one, so you can tell whether a slightly-off code is actually valid for an adjacent window. Never paste a real, production 2FA secret into any tool you do not fully trust and control; this one is safe by design because the secret lives only in memory for your current browser session. It is never written to storage, never sent to any server, and disappears the moment you close or refresh the tab.
