A TOTP is a time-based one-time password generated from a shared secret and the current time. Most services display a six-digit code that changes about every 30 seconds. The website and authenticator independently calculate matching values, so the code can work without an SMS or email being sent.
The standard behind TOTP
TOTP is specified in RFC 6238 as a time-based extension of the HMAC one-time password algorithm in RFC 4226. The shared secret is combined with a time counter using HMAC, then truncated into a short human-entered value.
The common default time step is 30 seconds, though a service can choose another period and supported algorithm. The generator and verifier must agree on the secret, algorithm, number of digits, and time step.
What happens during setup
A service creates a unique secret and usually presents it as a QR code or Base32 text. The user imports that secret into an authenticator. From then on, both sides can calculate the current code. The secret is not the six-digit code; it is the durable key that can generate every future code.
Treat the secret like a password. Anyone who copies it can generate valid values until the service rotates or removes it. Never place a real secret in a public screenshot, article, support ticket, analytics event, or shared test fixture.
Why the clock matters
The moving factor is derived from current Unix time divided into steps. If a device clock is far from the verifier’s clock, the generated value may not match. Verifiers often accept a small adjacent window to allow modest drift, but a large error still causes failure.
When codes repeatedly fail, confirm the account label, secret, algorithm, digits, and device time synchronization before generating many replacements. A changing code is expected; rapid retries can trigger login limits.
TOTP is a second factor, not a password replacement
In common use, the user enters a password and then the current TOTP. An attacker who steals only the password lacks the rotating code. This is a meaningful improvement, especially against password reuse and basic credential theft.
However, NIST guidance explains that manually entered OTP methods are not phishing-resistant. An impostor website can ask for a password and current code, then relay both immediately. Passkeys and FIDO security keys can bind authentication to the real website more strongly.
TOTP versus codes delivered by email
An email OTP requires the sender to generate and deliver a message through mail infrastructure. TOTP requires no delivery after setup; the authenticator calculates the value locally. Email can be delayed or rejected, while TOTP can fail because of a wrong secret or clock.
Email OTP proves access to the inbox. TOTP proves possession of the configured secret. Both can be useful, but neither proves that the website collecting the code is legitimate. The TOTP versus email OTP guide compares the threat and recovery tradeoffs.
Using an online TOTP generator safely
A browser-local generator can help with authorized testing or temporary recovery when you understand the risk. TempMail Cloud’s 2FA tool performs the calculation in the browser rather than intentionally sending the secret to the application server. Verify this behavior before using a sensitive secret and prefer a trusted offline authenticator for important accounts.
Do not use a shared or monitored computer, do not leave the secret in clipboard history, and close the page when finished. Rotate the secret at the service if you believe it was exposed.
Recovery and backup planning
Save the service’s recovery codes in a protected offline location and consider a second trusted authenticator or security key where allowed. Do not make one browser tab or one phone the only way back into a critical account.
For development, use test-only secrets that never grant production access. Check your implementation against published RFC test vectors rather than assuming that one observed code proves correctness.
Additional practical guidance
During enrollment, verify the issuer and account label, then test one code while recovery options are still available. Store recovery codes separately from the authenticator device. This quick setup check prevents a copied or mislabeled secret from becoming an emergency lockout later.
Related TempMail Cloud guides
You can also [create a receive-only inbox](/), review our safety guidance, or use the browser-local 2FA code generator.