π± TOTP 2FA Code Generator
Live 6-digit codes from any TOTP secret β computed 100% locally
Uses RFC 6238 TOTP (HMAC-SHA1, 30-second windows) β compatible with Google Authenticator, Authy, and most 2FA apps.
What exactly is a TOTP code, and why does it expire every 30 seconds?
TOTP stands for Time-based One-Time Password. The "time-based" part is the whole trick. When you set up two-factor authentication on an account, the service gives you a secret key β usually shown as a QR code. That secret never changes. What changes is the time. Your authenticator app and the server both look at the current time (in 30-second chunks) and run identical math on it. They get the same 6-digit result without ever talking to each other during login. That's why the code expires: the next 30-second window starts, the math changes, and the old code is no longer valid.
The standard behind this is RFC 6238, published by the IETF. Under the hood, it's built on HOTP (RFC 4226), which uses HMAC-SHA1 β a cryptographic function that takes a key and a message and produces a fixed-length fingerprint. For TOTP, the "message" is simply the count of 30-second intervals since January 1, 1970. The output is truncated and reduced to a 6-digit number. It's beautifully simple, which is partly why it's been the global standard for a decade.
How does this tool compute the code β is it really happening locally?
Yes, completely locally. The tool uses the Web Crypto API (crypto.subtle), which is built into every modern browser. There is no server involved at any point. When you type or paste your secret key, the following steps happen entirely inside your browser tab:
- Your Base32 secret is decoded into raw bytes β the actual cryptographic key.
- The current Unix timestamp is divided by 30 and floored to get the counter value (a number representing which 30-second window we're in).
- That counter is encoded as an 8-byte big-endian integer and passed to HMAC-SHA1 along with your key bytes.
- The resulting 20-byte HMAC output is truncated using a technique called dynamic truncation: the last byte's low 4 bits determine an offset, and 4 bytes at that offset are read and masked to produce a 31-bit integer.
- That integer is taken modulo 1,000,000 and padded to 6 digits.
This is exactly what Google Authenticator, Authy, Microsoft Authenticator, and every other RFC 6238 compliant app does. The math is identical, which is why the codes match.
What is Base32 and why do TOTP secrets use it?
Base32 is an encoding scheme that represents binary data using only 32 characters: the uppercase letters A through Z and the digits 2 through 7. It deliberately skips characters that look similar to each other β no 0 (zero) and no 1 (one) because they're easily confused with O and I. No lowercase, so it's case-insensitive.
TOTP secrets are binary data (typically 10 to 20 bytes of random entropy). To display them to humans β in a backup code, in a URL, or in an on-screen text field β you need an encoding. Base32 was chosen because it's compact, human-readable, case-insensitive, and easy to type without mistakes. The QR code that most services show you is just a convenient way to transfer the same Base32 string without typing it manually.
When you paste a secret into this tool, it's Base32-decoded back to raw bytes before any cryptographic math happens. If your secret contains characters outside AβZ and 2β7, the tool will flag it immediately.
When would I actually need to generate a TOTP code manually like this?
The most common scenario is recovery. You've lost your phone, your authenticator app data got wiped after a factory reset, or you switched devices and forgot to migrate your 2FA entries. If you kept a copy of the original secret key (from the setup QR code or the "show secret" link most sites offer), you can enter it here and get valid codes to log back in.
The second scenario is development and testing. If you're building a web app or API that supports TOTP-based 2FA, you need to verify your implementation works correctly. Paste the secret your server generated, check what code this tool produces, and confirm your server accepts it. Since this tool implements the same RFC 6238 algorithm, agreement between the two confirms your implementation is correct.
A third use case is setting up a new device when you already have the secret saved somewhere (a password manager, an encrypted note, a printed backup). Rather than scanning a QR code, you can manually enter the Base32 secret into any authenticator app β or use this tool temporarily while you're getting the new app configured.
Is it safe to enter my real TOTP secret into a web tool?
With this particular tool, yes β because it makes zero network requests. You can verify this with your browser's developer tools: open the Network tab, then type a secret into the tool. You will see no outbound requests of any kind. The computation uses crypto.subtle, a browser-native cryptographic API that doesn't leave your device.
The general principle to follow with any online tool: if you have any doubt, disconnect from the internet before using it. A tool that runs purely in JavaScript with no external dependencies will work just as well offline. As a habit, be wary of any "TOTP generator" that requires you to submit a form, sends data to a backend, or needs a server to compute the code. None of that is necessary, and it creates unnecessary risk.
Also worth noting: a TOTP code alone is not dangerous to expose. It's valid for at most 30 seconds, and it's useless without your password. The secret key itself is the sensitive piece β treat it like a password. Don't paste it into random online tools that might log inputs.
What's the difference between TOTP and SMS-based 2FA?
SMS 2FA sends a one-time code to your phone number via text message. TOTP generates the code locally using a shared secret. This difference matters a lot for security.
SMS codes can be intercepted through SIM swapping β an attack where a criminal convinces your mobile carrier to transfer your phone number to a SIM they control. Once they have your number, they receive your SMS codes. This attack has been used to drain cryptocurrency wallets, take over email accounts, and break into banking apps. It requires no technical skill; it's often just a social engineering call to a carrier support rep.
TOTP has no such vulnerability. There's no phone number to hijack. The code is generated from a secret stored only on your device and on the server. Even if an attacker is watching your network traffic, a used TOTP code is worthless β it expires in seconds and can only be used once per window. For any account that offers TOTP as an option alongside SMS, TOTP is the stronger choice.
Why do I sometimes see "6 digits" and sometimes "8 digits" in authenticator codes?
The RFC 6238 standard supports configurable code length. The most common setting β used by the overwhelming majority of consumer services β is 6 digits. Some enterprise systems, particularly those with stricter security requirements, use 8-digit codes. The underlying algorithm is the same; you just take modulo 100,000,000 instead of 1,000,000 at the final step.
Similarly, the 30-second window is a convention, not a hard requirement. Some systems use 60-second windows. If a code from this tool doesn't work on a particular service, it's possible that service uses a non-standard digit count or time step. This tool implements the standard 6-digit, 30-second configuration, which covers the vast majority of services worldwide.