How to use the 2FA code generator
When the page loads, a cryptographically random Base32 secret is generated automatically using the Web Crypto API. This secret is the shared key that both your application and the authenticator app use to generate matching codes. You can generate a new random secret by clicking the "New" button, or paste an existing secret if you're testing against a known key.
Configure the issuer name (your application or company name) and account identifier (typically an email address). These values are embedded in the otpauth:// URI, which authenticator apps display to help users identify which service the code belongs to. Set the period (default 30 seconds) and digit count (6 or 8) to match your server-side TOTP configuration.
The live TOTP code updates every second and regenerates when the time period expires. The progress bar shows how much time remains before the current code rotates. Copy the code, the secret, or the full otpauth:// URI using the copy buttons. The otpauth URI can be embedded in a QR code for authenticator app enrollment during your development and testing workflow.
How TOTP authentication works
TOTP (Time-based One-Time Password) is defined in RFC 6238 and builds on the HOTP (HMAC-based One-Time Password) specification from RFC 4226. The core mechanism combines a shared secret key with the current Unix timestamp divided by a time step (typically 30 seconds) to produce a counter value. This counter is fed into HMAC-SHA1 along with the secret key to generate a 20-byte hash.
From this hash, a 4-byte value is extracted using dynamic truncation: the last nibble of the hash determines the byte offset, and four consecutive bytes from that offset form a 31-bit integer (the high bit is masked to avoid signed integer issues). This integer is then reduced modulo 10^d (where d is the digit count, usually 6) to produce the final code. The entire process is deterministic—given the same secret and the same time window, both the server and client independently compute the same code.
Servers typically accept codes from adjacent time windows (the previous, current, and next periods) to tolerate minor clock differences between devices. This provides a ±30 second acceptance window by default. More sophisticated implementations track clock drift per user and adjust the acceptance window dynamically, but the basic 3-window approach works well for most applications.
Implementing 2FA in your application
To add TOTP 2FA to your application, start with the enrollment flow: generate a random secret on the server, present it to the user as both a Base32 string and a QR code containing the otpauth:// URI. The user scans the QR code with their authenticator app, which stores the secret. Before enabling 2FA, require the user to enter a valid code to confirm their authenticator is set up correctly.
On the server side, store the secret securely (encrypted at rest) alongside the user record. During login, after the user provides their password, prompt for the TOTP code. Verify the code by computing TOTP for the current and adjacent time windows using the stored secret. Use constant-time comparison to prevent timing attacks. Rate-limit verification attempts to prevent brute force attacks on the 6-digit code space (1 million combinations).
Always provide recovery options: generate a set of one-time backup codes during enrollment that the user can store safely. These codes bypass TOTP when the authenticator device is lost. Consider supporting multiple authentication methods (TOTP, WebAuthn/FIDO2, SMS as fallback) to balance security with usability. Popular server-side libraries include speakeasy and otplib for Node.js, pyotp for Python, and rotp for Ruby.
Frequently Asked Questions
What is 2FA / TOTP?
Two-Factor Authentication (2FA) adds a second layer of security beyond passwords. TOTP (Time-based One-Time Password) generates a short numeric code that changes every 30 seconds based on a shared secret and the current time. It's defined in RFC 6238 and used by Google Authenticator, Authy, Microsoft Authenticator, and most 2FA-enabled services.
How does TOTP work?
TOTP combines a shared secret key with the current Unix timestamp divided by a time period (usually 30 seconds). This value is passed through HMAC-SHA1 to produce a hash, from which a 6 or 8 digit code is extracted using dynamic truncation. Because both the server and authenticator app share the same secret and use the same clock, they independently generate matching codes.
What is the Base32 secret?
The secret key is encoded in Base32 (characters A–Z and 2–7) for compatibility with authenticator apps. Base32 is case-insensitive and avoids ambiguous characters, making it easier to manually enter if needed. A 32-character Base32 secret provides 160 bits of entropy, which is well above the minimum 128 bits recommended by RFC 4226.
Can I use this for production 2FA setup?
This tool generates cryptographically random secrets and real TOTP codes using the Web Crypto API. However, production 2FA implementation requires secure server-side secret storage, backup/recovery codes, rate limiting, and proper enrollment flows. Use this tool for development, testing, and understanding TOTP before implementing it in your application.
What is the otpauth:// URI?
The otpauth:// URI is a standard format for provisioning TOTP secrets to authenticator apps. It contains the secret, issuer, account name, algorithm, digit count, and period. This URI is typically embedded in a QR code that users scan with their authenticator app during 2FA enrollment. The format is: otpauth://totp/Issuer:Account?secret=KEY&issuer=Issuer&algorithm=SHA1&digits=6&period=30.
Why does the code change every 30 seconds?
The 30-second period balances security and usability. Shorter periods would require faster entry and tighter clock synchronization. Longer periods increase the window during which a stolen code remains valid. Most implementations accept codes from the current and adjacent time windows (±30 seconds) to account for minor clock drift between devices.
Privacy and methodology
This tool runs entirely in your browser using the Web Crypto API for HMAC-SHA1 computation and cryptographic random number generation. Secrets and codes are never sent to any server. The TOTP implementation follows RFC 6238 with standard Base32 encoding, HMAC-SHA1, dynamic truncation, and configurable period and digit count. Safe for development and testing use.