What Is TOTP? Is an Online 2FA Generator Safe?

Published

TOTP explained via RFC 6238: how the 30-second time step and shared secret work, plus an honest look at when a browser-based 2FA generator is safe to use.

TOTP is a two-factor authentication algorithm, defined in RFC 6238, that turns a shared secret plus the current clock time into a short code that expires every 30 seconds. An online 2FA generator that computes codes entirely in your browser is cryptographically correct, but it is not equivalent to a dedicated authenticator app. The difference is not the math. It is where your secret ends up.

What does TOTP actually stand for, and how does it work?

TOTP means Time-based One-Time Password. It is a thin layer over an older algorithm, HOTP, specified in RFC 4226, which generates a code from a shared secret and a counter that increments with each use. The weakness is apparent: if your counter and the server's fall out of step, nothing matches.

TOTP replaces that event counter with the clock. The specification writes it as TOTP = HOTP(K, T), where K is your shared secret and T is a time-step number, computed by taking the current Unix time, subtracting a start time T0, and dividing by a step size X, discarding the remainder. RFC 6238 sets the defaults plainly: X is 30 seconds, T0 is 0, the Unix epoch.

So both sides run the same calculation independently. Your phone never talks to the server, because it does not need to: both know the secret and both know roughly what time it is, so both arrive at the same six digits. That is why authenticator apps work on a plane with no signal.

Under the hood, the secret and time-step are run through HMAC, then part of the resulting hash is truncated to six digits. HOTP uses HMAC-SHA-1. RFC 6238 says TOTP implementations may instead use HMAC-SHA-256 or HMAC-SHA-512, though most consumer services stayed on SHA-1 for compatibility, which is acceptable here because HMAC-SHA-1 is not affected by the collision attacks that broke SHA-1 for signatures.

What is a TOTP shared secret?

The shared secret is the one piece of data that matters. When a service shows you a QR code during 2FA setup, that image is a wrapper around a text string in otpauth:// format containing a random key encoded in Base32, usually printed beside the QR as a 16 or 32 character string. The service keeps a copy, your authenticator keeps a copy, and nobody else should ever have one.

Treat the secret as equal in value to a password, because functionally that is what it is: a long-lived credential from which unlimited future codes can be derived. A six-digit code is worthless thirty seconds after it appears; the secret behind it keeps producing valid codes for as long as the account exists. Anyone holding it can generate the same codes you can, at any time, from anywhere, without touching your phone. RFC 6238 is direct here, recommending that keys be generated randomly, transmitted only over a secure channel, and stored encrypted.

Is an online 2FA code generator safe?

The honest answer is more complicated than either "yes, it is client-side" or "no, never".

The generator on our 2FA code generator page computes codes in your browser using the WebCrypto API. No network request carries your secret anywhere, nothing is written to storage, and closing the tab discards it. That is verifiable rather than a promise: open your browser's developer tools, switch to the Network tab, paste a secret, and watch that no request leaves the page. Do exactly that with any tool like this, including ours.

That protects against one specific threat, a server-side operator logging your secret, which is a real risk with tools that POST your key for processing. What it does not protect against is rather a lot.

  • A compromised page. Client-side code is trustworthy only while the code served to you is the code you inspected. A site owner who changes the script tomorrow, or an attacker who compromises the server or a dependency, can exfiltrate secrets with no visible change to the page.
  • The wrong site entirely. Typo a domain or follow a search ad and you may be pasting your secret into a lookalike built for the purpose, one that copies a legitimate tool's layout and its reassuring privacy text word for word.
  • Your own machine. Malware in your browser, a malicious extension with permission to read page content, or a shared computer defeats client-side processing completely.
  • Single-factor collapse. Two-factor authentication works because the factors are separate. Keep the password in your browser's password manager and generate the code in the same browser, and an attacker controlling that device has both. The second factor stops being one.

When is a browser-based generator reasonable?

There are legitimate uses, and pretending otherwise is not useful. It is a sensible choice when you already hold the secret and need a code right now: the key is written down or stored in a password manager, your phone is lost, flat, or being replaced, and you need to get in to re-enroll properly. It is also reasonable for developers testing a TOTP implementation, where comparing a server's output against a known-good generator is normal debugging, and for low-value accounts where the realistic consequence of compromise is small.

It is the wrong tool for your email, your password manager, your bank, your domain registrar, your cloud infrastructure, or any account that can reset access to the others. For those, the secret should live in something built to hold it.

MethodWhere the secret livesPhishing resistantBest suited to
Hardware security key (FIDO2/WebAuthn)Dedicated chip, never leaves the deviceYes, by designEmail, password managers, admin and financial accounts
Authenticator app on a phoneEncrypted app storage on your deviceNoEveryday 2FA for most accounts
Desktop password manager with TOTPEncrypted vaultNoConvenient, but weakens factor separation
Browser-based generatorNowhere, discarded on closeNoTesting, recovery when you already hold the secret
SMS codesYour phone number, controlled by your carrierNoLast resort when nothing else is offered

That ranking is about the secret's exposure, not the strength of the algorithm. A hardware key wins because its private key is generated inside the device and cannot be read out, and because WebAuthn binds the login to the real domain, so a phishing site cannot replay it. TOTP lacks that binding: a convincing fake login page can ask for your six digits and use them immediately.

Why is SMS the weakest option?

SMS depends on your mobile carrier keeping your phone number pointed at your phone, and that has proven a weak link. NIST's digital identity guidelines in SP 800-63B classify use of the public telephone network for out-of-band verification as RESTRICTED, and advise verifiers to watch for risk indicators including device swap, SIM change, and number porting before sending a code. Organizations using a restricted authenticator are expected to offer at least one alternative that is not restricted.

That is standards-body language for a known attack: persuade or bribe a carrier representative to move a number to a new SIM, and the codes follow. Any TOTP method avoids the carrier entirely. SMS still beats no second factor, so if a service offers nothing else, turn it on.

Practical rules for handling TOTP secrets

A few habits cover most of the risk. Save the secret at setup time, in your password manager or on paper somewhere secure, because recovering a lost secret is far harder than storing one. Download the recovery codes at the same time and keep them separately. Never paste a secret into a site you reached from an ad, an email, or a message, and never into a tool that asks for your username and password alongside the key, which is a strong signal you are being phished. If you suspect a secret has leaked, disable and re-enable 2FA to rotate it, since the old secret stays valid until you do.

If you lost your codes and saved no secret, no generator can help. The route back is platform account recovery, covered in our guide to recovery options when you lose access to your 2FA codes. Anyone advertising a service that bypasses two-factor authentication is running a scam.

Frequently asked questions

Does an online TOTP generator produce the same codes as Google Authenticator?

Yes, given the same secret and settings. TOTP is a published standard, so every correct implementation produces identical codes for a given secret and time-step. If codes differ, suspect a mistyped Base32 secret, a wrong device clock, or non-default parameters such as a 60-second step or 8-digit output.

Why is my TOTP code rejected as invalid?

Clock drift is the usual cause. Because the code derives from the current time, a device clock off by more than roughly a minute produces codes the server rejects. Enable automatic time sync. RFC 6238 lets validators accept a small window of past time-steps, but that tolerance is deliberately narrow.

Can someone steal my account using one TOTP code?

Only within a very short window, and only with your password too. A used code should be rejected on reuse and expires with its time-step. The serious risk is the shared secret, which generates valid codes indefinitely.

Is it safe to store TOTP secrets in my password manager?

It is a trade-off many security teams accept, though it reduces factor separation, since one compromised vault yields both password and code. A vault with a strong unique master password and its own hardware-key second factor is defensible. Keeping the second factor on a separate device is stronger.

What happens if I lose the device holding my authenticator?

You use your recovery codes, or a backup method enrolled earlier, then re-enroll a new device and rotate the secret. This is why saving the secret and recovery codes during setup matters. Platform recovery without either is slow and sometimes unsuccessful.

Does 2uid.net store the secret I paste into the generator?

No. The code is computed in your browser with the WebCrypto API, the secret is never transmitted or written to storage, and it is discarded when you close the tab. Confirm it yourself in the Network tab, and apply that check to any tool handling a secret.

Is TOTP still strong enough?

TOTP remains a solid second factor and a large improvement over password-only login, but it is not phishing resistant: a fake login page can collect a code and use it instantly. For high-value accounts a FIDO2 hardware key or passkey is stronger, being bound to the real domain. Elsewhere, TOTP in a dedicated app is a sensible default.

Our Facebook UID Finder and the lookup tools for Instagram and TikTok handle public identifiers only and never require credentials. For wider hardening, see our Facebook security checklist.