What Is a TOTP Code and How Does a 2FA Generator Work?
A TOTP code is a short numeric password derived from two inputs: a secret key shared once between you and a service, and the current time. Both sides compute the same code independently, so nothing is transmitted. Defined in RFC 6238, it typically produces six digits that change every 30 seconds.
What does TOTP stand for, and how is it different from an SMS code?
TOTP means Time-based One-Time Password. The distinction from an SMS code is the one that matters for your security, and it is worth getting straight.
An SMS code is sent to you. A server generates it, hands it to a mobile network, and the network delivers it to your phone number. That delivery path is the weakness: phone numbers can be transferred to an attacker through SIM swapping, and the message travels through infrastructure neither you nor the service controls.
A TOTP code is not sent anywhere. Your authenticator app computes it on your device from a secret it already holds, and the server computes the same value independently from its own copy of that secret. The code crosses the network only when you type it into a login form. There is no delivery to intercept and no phone number to hijack, which is why security guidance generally favours app-based codes over SMS.
How does a 2FA generator actually produce the code?
The mechanism is short enough to explain properly, and understanding it demystifies most of the problems people run into.
First, a shared secret. When you enable two-factor authentication, the service generates a random secret key and shows it to you, usually as a QR code with a Base32 text string behind it. Base32 uses only the letters A to Z and the digits 2 to 7, which is why a secret never contains the digits 0, 1, 8 or 9. Your app stores that secret. The service stores its own copy. This exchange happens exactly once, during setup.
Second, a time counter. Both sides take the current Unix time and divide it by the time step, conventionally 30 seconds, discarding the remainder. That integer is the moving factor. Because it derives from the clock rather than from a message, both sides arrive at the same number without communicating.
Third, an HMAC. The secret is used as an HMAC key over that counter value. RFC 6238 builds on the earlier HOTP specification in RFC 4226, which uses HMAC-SHA-1, and RFC 6238 permits SHA-256 and SHA-512 variants as well. HMAC is a one-way operation, so the resulting digest cannot be reversed to recover the secret.
Fourth, truncation. The digest is longer than a code a human would type, so a defined truncation step extracts a portion and reduces it modulo a power of ten, yielding the six digits you see. Some services use eight.
The 2FA code generator on finduid.net implements exactly this: it decodes your Base32 secret, builds the 30-second time counter, computes the HMAC-SHA-1 digest and truncates it to six digits, entirely in JavaScript in your browser. The secret is never sent to any server, because the computation does not require one.
Why does the code sometimes still work after it changes?
Clock drift. Your device and the server will not agree to the millisecond, and a code generated a moment before a boundary may arrive a moment after it. RFC 6238 addresses this by letting a validator accept a code from an adjacent time step, which is why a code occasionally works slightly past its apparent expiry. That tolerance is deliberately small, since every accepted step widens the window an attacker has to reuse a stolen code.
Why would you use a browser-based generator instead of an app?
Honestly: for most people, most of the time, a dedicated authenticator app on a phone is the better default, and a browser tool is for specific situations. Here is the real comparison.
| Property | Authenticator app | Browser-based generator |
|---|---|---|
| Where the secret is stored | Persistently on the device | Not stored; pasted each time |
| Works offline | Yes | Yes, once the page is loaded |
| Setup effort | Install, scan QR, manage device | None |
| Risk if the device is lost | Secret may be lost with it | Nothing stored to lose |
| Risk from the surrounding environment | Isolated app sandbox | Depends on the browser and machine |
| Best suited to | Everyday accounts | Verification, testing, recovery checks |
Reasonable uses for a browser generator: confirming that a secret you backed up still produces valid codes, checking a service's setup flow while developing or testing, accessing a shared service account where a secret is held in a team password manager, or getting into an account when your phone is unavailable and you have your backup secret.
Where an app wins: your routine accounts. A phone app keeps the secret in an isolated store, needs no copy-pasting of sensitive strings, and is harder to get wrong. A hardware security key is better still for high-value accounts, since it resists phishing in a way no typed code can.
How should you handle a TOTP secret?
This is the section that matters most, because the secret is the whole system. Treat it exactly as you treat a password, with one additional property: anyone holding it can generate valid codes for that account indefinitely, from anywhere, without you noticing.
Use the generator only for your own accounts, or accounts you are authorised to administer. A TOTP secret belonging to someone else is not yours to compute codes from, and doing so to reach an account you do not own is unauthorised access regardless of how you obtained the string.
Never paste a secret into a service that sends it anywhere. The computation is pure arithmetic that runs locally, so there is no legitimate reason for a secret to leave your device. The tool here runs in your browser precisely for this reason.
Store backups somewhere encrypted. A password manager is appropriate. A plain text file, a notes app, a screenshot in your camera roll, or an email to yourself are not, because each of those gets copied and synced to places you have stopped thinking about.
Never share a secret over chat or email. If a colleague needs access, use a shared password manager vault rather than pasting the string into a conversation that will persist forever in someone's history.
Save recovery codes at setup. Most services offer single-use backup codes alongside the TOTP secret. Those are the route back in if you lose access to your generator, and people reliably skip this step and regret it.
Mind the machine. A browser-based generator is only as trustworthy as the computer running it. On a shared or public machine, assume the clipboard and keystrokes may not be private, and do not paste secrets there.
What TOTP does not protect you from
Two-factor authentication is a large improvement over a password alone, and it is not a complete defence. Being clear about the gaps is more useful than overselling it.
Real-time phishing still works. A convincing fake login page can ask for your password and your current code and relay both to the real service within the 30-second window. The code is valid, so the attacker gets in. This is the main reason hardware keys using origin-bound protocols are recommended for high-value accounts: they cannot be replayed to a different domain.
A compromised secret is a lasting compromise. Unlike a stolen code, which expires in seconds, a stolen secret keeps producing valid codes until you re-enrol the account.
Device malware sees what you see. If your machine is compromised, so is anything you type or paste on it.
Account recovery is often the weakest link. An attacker who can persuade a support process to reset your two-factor setup does not need to break TOTP at all.
finduid.net is not affiliated with any of the services you may use TOTP with, and the generator here needs no login and sends nothing anywhere. If you are looking at the site's other utilities, the open port checker and tool guides sit alongside it.
Frequently Asked Questions
Is it safe to paste my 2FA secret into a website?
Only into a tool that computes the code locally in your browser and sends nothing to a server, and only on a machine you trust. The finduid.net generator runs entirely in JavaScript on your device. Avoid pasting secrets on shared or public computers, where the clipboard and keystrokes may not be private.
Why does my TOTP code get rejected as invalid?
Clock drift is the usual cause: if your device's time is wrong, the time counter differs from the server's and the computed code will not match. Enable automatic time synchronisation. Other causes are a mistyped Base32 secret, or using a secret from a different account than the one you are logging into.
Can someone generate my codes if they have my secret key?
Yes, indefinitely, from anywhere, until you re-enrol that account with a new secret. This is why a TOTP secret deserves more care than a single code: a stolen code expires in seconds, whereas a stolen secret keeps producing valid codes. If a secret leaks, regenerate your two-factor setup immediately.
Does TOTP work without an internet connection?
Yes. The code derives from your stored secret and your device clock, with no server contact needed, so an authenticator works in airplane mode. You need connectivity only to submit the code to the service you are logging into. A browser-based generator works offline once the page has loaded.
Why are codes always six digits and 30 seconds?
Those are conventions rather than hard requirements. RFC 6238 defines the algorithm with a configurable time step and code length, and some services use eight digits or a different interval. Six digits over 30 seconds became the widespread default because it balances typing effort against the window an attacker has.
Is TOTP better than SMS two-factor authentication?
Generally yes. An SMS code is delivered over the mobile network, which exposes it to SIM-swap attacks and infrastructure outside your control. A TOTP code is computed on your device and never transmitted until you type it. For high-value accounts, a hardware security key is stronger than either, since it resists phishing.