TOTP 2FA Code Generator — Test Authenticator Codes

What TOTP Is and Why It Matters

Two-factor authentication significantly reduces account takeover risk. Even if a password is compromised through phishing or a database breach, the attacker still needs the rotating 6-digit code to log in — and that code expires every 30 seconds. TOTP is the most widely deployed 2FA mechanism because it works offline, requires no SMS, and runs on any smartphone.

For developers, implementing TOTP correctly requires understanding the algorithm well enough to generate codes that match a reference implementation. The TOTP 2FA code generator runs the full RFC 6238 algorithm in your browser using the Web Crypto API, so you can verify codes against your server implementation without installing any software.

How the TOTP Algorithm Works

TOTP is defined in RFC 6238 as an extension of HOTP (RFC 4226). The computation has four steps:

1. Decode the secret key from base32 to raw bytes. The secret is typically 20 bytes (160 bits).
2. Compute the time step counter: T = floor(Unix time / 30). This counter advances by 1 every 30 seconds and is the same for any two clocks within the same 30-second window.
3. HMAC-SHA1 the 8-byte big-endian representation of T with the decoded secret key. The result is a 20-byte digest.
4. Dynamic truncation: take the last nibble of the HMAC as an offset into the digest. Extract 4 bytes at that offset, mask the top bit to get a 31-bit integer, then take modulo 1,000,000 to produce a 6-digit code. Pad with leading zeros if necessary.

Because both the server and the authenticator app know the shared secret and both read the same Unix clock, they independently produce identical codes — without communicating.

TOTP Properties Reference

Advanced Workflows

Testing a 2FA Server Implementation

When building TOTP on the server side, generate a test secret, compute the expected codes with the browser tool, and compare them with what your server validates. A mismatch almost always indicates one of three things: the secret is decoded incorrectly (wrong base32 padding handling), the clock is wrong (server is in a different timezone than expected — all TOTP computation should use UTC Unix time), or the period or digit count differs from the default.

Generating the otpauth:// URI

The otpauth:// URI is the standard interchange format for TOTP configuration. It encodes everything an authenticator app needs: the secret, the issuer name, the account label, and the algorithm parameters. The format is:

otpauth://totp/Issuer:account@example.com?secret=BASE32SECRET&issuer=Issuer&algorithm=SHA1&digits=6&period=30

Converting this URI to a QR code lets users scan it directly into Google Authenticator, Authy, Bitwarden, or any RFC 6238 app. The tool generates this URI automatically when you enter an account name and issuer — copy it and feed it to the QR code generator to produce a scannable image.

Using the Next Code for Automated Tests

Automated tests that exercise 2FA flows are timing-sensitive. If a test starts near the end of a 30-second window, the code may expire mid-test and the assertion fails. The safest approach: check the countdown before your test runs, and if fewer than 5 seconds remain, wait for the window to roll over and use the next code. The tool shows both the current and next code to support this workflow.

Handling Clock Drift

TOTP breaks when server and client clocks diverge significantly. In production, ensure your servers sync with NTP. In code, implement a tolerance window: accept the code from T-1, T, and T+1 (i.e., the 90 seconds centered on the current window). When a user's code at T-1 succeeds, you can infer their device clock is 30 seconds behind and adjust tolerance for that user's subsequent logins.

Rate Limiting and Code Reuse Prevention

A valid TOTP code should only be accepted once within its 30-second window. If an attacker captures a code in transit, they have at most 30 seconds to use it — but only if you prevent replay. Store the last used counter value per user and reject any code with the same or lower counter, even if it passes HMAC verification.

Common Questions

Is TOTP the same as Google Authenticator?

Google Authenticator is an app that implements the TOTP standard. The algorithm is open — any app that follows RFC 6238 produces identical codes for the same secret and time step. This is why you can import the same account into Authy, 1Password, Bitwarden, or any other TOTP-compatible app and get the same codes.

What is the difference between TOTP and SMS 2FA?

SMS 2FA sends a one-time code via text message to a phone number. TOTP generates codes locally on the device without any network communication. TOTP is more secure: SMS is vulnerable to SIM swapping attacks, carrier-level interception, and SS7 exploits. TOTP codes cannot be intercepted in transit because they are never transmitted. NIST deprecated SMS-based authentication in SP 800-63B in 2016 for high-assurance applications.

What happens if I lose my authenticator device?

Without a backup of the secret key, the account is locked out. Production systems must provide account recovery flows (backup codes, support-assisted recovery). When setting up TOTP, display the secret key as a copyable string alongside the QR code so users can back it up in a password manager.

Can I implement TOTP without a library?

Yes — the algorithm is compact enough to implement from scratch. This tool does exactly that: base32 decode, HMAC-SHA1 via Web Crypto, and dynamic truncation in under 40 lines. In Node.js, use crypto.createHmac; in Python, use hmac.new. If you want a battle-tested library, pyotp (Python), speakeasy (Node.js), and otp (Go) are widely used.