TOTP / 2FA Code Generator
Generate live TOTP authenticator codes from any base32 secret key — for testing 2FA flows, verifying server implementations, or exploring RFC 6238. No signup, runs entirely in your browser. Your secret never leaves your device.
⏱ 7 min read · Complete guide below
Current Code
Refreshes in 7s
Next Code
--- ---Valid in 7s
How the TOTP Generator Works
- 1Enter or generate a base32 secret key — this is the shared secret that seeds the TOTP algorithm. Click Generate for a fresh cryptographically random key.
- 2Optionally add an account name and issuer — these appear in the
otpauth://URI and in the authenticator app after scanning. - 3The tool displays the current 6-digit code with a live countdown bar showing seconds until the next rotation, plus the next code for planning ahead.
- 4Copy the otpauth:// URI and convert it to a QR code to scan with any RFC 6238 authenticator app (Google Authenticator, Authy, Bitwarden, 1Password).
How TOTP Codes Are Generated
The TOTP algorithm (RFC 6238) computes an HMAC-SHA1 of the base32-decoded secret key and an 8-byte big-endian representation of the current Unix time divided by 30. The last byte of the HMAC determines an offset into the result; four bytes at that offset are extracted, the top bit is cleared to produce a 31-bit integer, and the result is taken modulo 1,000,000 to produce a 6-digit code. All of this runs inside your browser using the Web Crypto API — the secret key is processed locally and never transmitted.
Why TOTP Beats SMS for Two-Factor Authentication
Two-factor authentication adds a second proof of identity on top of your password, so that a stolen password alone is not enough to break into an account. TOTP — the codes produced by apps like Google Authenticator, Authy, 1Password, and Bitwarden — is widely considered more secure than SMS codes, and understanding why is useful. SMS one-time codes travel over the phone network, where they can be intercepted through SIM-swapping attacks (a scammer convinces your carrier to move your number to their SIM) or SS7 signalling weaknesses. TOTP has no such exposure: the code is computed entirely offline from a shared secret and the current time, so there is nothing to intercept in transit and no dependence on your carrier. The trade-off is that you must keep the secret (and a backup) safe, since anyone who has it can generate valid codes.
The Shared Secret and the QR-Code Setup Flow
Everything hinges on a single shared secret — a random base32 string that the server and your authenticator both hold. When you enable 2FA on a website, the server generates this secret and shows it to you, usually as a QR code that encodes an otpauth://URI containing the secret plus metadata (the account name, issuer, algorithm, digit count, and 30-second period). Your authenticator app scans that QR code, stores the secret, and from then on both sides independently compute the same time-based code every 30 seconds without ever communicating again. That is why this tool lets you generate a secret and copy the otpauth:// URI: turning that URI into a QR code reproduces exactly the enrolment flow your users will follow, which makes it ideal for testing a 2FA implementation end to end without a physical phone.
Clock Drift, Time Windows, and Why Codes Sometimes Fail
Because TOTP derives the code from the current time, both the server and the client must agree on the time reasonably closely. Each code is valid for a 30-second window, and a well-built server accepts codes from the adjacent windows too — typically the previous and next 30 seconds — to tolerate small clock drift between devices. This is why a code can occasionally be rejected: if your phone's clock has drifted by more than a window, the codes it produces no longer line up with the server's. The fix is almost always to ensure the device is set to automatic network time; some authenticator apps also offer a “sync time” option that corrects for drift internally. When testing, watch the countdown here and avoid submitting a code in its final second or two, since it may expire between reading and entering it.
Backup Codes and Recovery
The flip side of TOTP's offline strength is that losing the secret means losing access. If your phone is lost, wiped, or upgraded without migrating your authenticator, the codes are gone. This is why services issue one-time backup (recovery) codes when you enable 2FA — store them somewhere safe and offline, because they are your way back in if the authenticator is unavailable. Many people also keep their TOTP secrets in a password manager that supports 2FA, or in an app with encrypted cloud backup, so a lost device does not lock them out. From a developer's perspective, providing clear recovery options and generous backup codes is as important as implementing the algorithm correctly, because account lockouts are one of the most common support burdens that 2FA introduces.
Tips for Testing 2FA Implementations
Always test with a known secret
When building a TOTP server, start with a fixed known secret and verify the generated codes against a reference tool before integrating a real authenticator app.
Allow a ±1 window on the server
Accept codes from the previous and next 30-second window in addition to the current one. This accounts for up to 30 seconds of clock drift between the user's device and your server.
Use the Next Code for CI tests
When writing automated tests, avoid triggering code refreshes mid-test. Check the countdown — if under 5 seconds, wait for the next window and use the Next Code shown here.
Encode the URI as a QR code
Once you have your otpauth:// URI, feed it to a QR code generator to produce a scannable image. This replicates the exact setup flow your users will follow in production.
Keep secrets 20 bytes (160 bits)
RFC 6238 recommends at least 128 bits, but 160-bit (20-byte) secrets are the convention. The Generate button produces exactly 20 random bytes, encoded to base32.
Never reuse secrets across accounts
Each account in your system should have its own unique TOTP secret. Sharing secrets across users means one compromise exposes all of them.
Frequently Asked Questions
What is TOTP and how does it work?
TOTP (Time-based One-Time Password) is the algorithm behind most authenticator apps. It generates a 6-digit code by computing HMAC-SHA1 of a shared secret and the current 30-second time window, then truncating the result to 6 digits. Because both the server and the app use the same secret and the same time, they produce identical codes — but the code is only valid for 30 seconds.
Is it safe to enter my real 2FA secret here?
This tool runs entirely in your browser using the Web Crypto API. Your secret key is never sent to any server and is discarded when you close or refresh the page. That said, for production accounts you care about, best practice is to use this tool with test secrets only, and manage your real 2FA secrets exclusively through your authenticator app.
What is a base32 secret key?
A base32 secret is the shared key that seeds your authenticator. It consists of uppercase letters A–Z and digits 2–7 (32 characters total — hence "base32"). When you set up 2FA on a website, they show you this key either as a QR code or as a plain base32 string you can copy. The "Generate" button creates a cryptographically random 20-byte (160-bit) secret encoded in base32.
What is the otpauth:// URI for?
The otpauth:// URI is the standard format used by authenticator apps to import a TOTP account. When you convert this URI into a QR code, you can scan it with Google Authenticator, Authy, 1Password, Bitwarden, or any RFC 6238-compatible app. The URI encodes the secret, account name, issuer, algorithm, digit count, and time period into a single scannable string.
Why does the code change every 30 seconds?
The 30-second window is the default TOTP period defined in RFC 6238. It balances security (short enough that a stolen code has limited value) with usability (long enough that users can read and type the code comfortably). Most servers accept codes from the current, previous, and occasionally next window to account for clock drift.
What is the difference between TOTP and HOTP?
HOTP (HMAC-based OTP, RFC 4226) generates codes based on a counter that increments with each use. TOTP (RFC 6238) extends HOTP by deriving the counter from the current Unix time divided by the period (30 seconds). TOTP is the standard used by most modern 2FA implementations because it does not require synchronized counters between client and server.
Can I use this to test my own 2FA implementation?
Yes. Generate a random secret, copy the otpauth:// URI, and compare the codes this tool produces against what your server validates. As long as both use the same secret, the same time source, and the same algorithm parameters (SHA1, 6 digits, 30-second period), the codes should match. This is useful for testing TOTP during development without needing a phone.