Hashes/Crypto

TOTP Generator/Verifier

Time-based one-time passwords (TOTP, RFC 6238) — generate the current code from a secret and verify an entered code with clock-drift tolerance.

------


                    

TOTP (Time-based One-Time Password, RFC 6238) is a two-factor authentication algorithm that generates a one-time code from a secret and the current time. It's exactly what runs under the hood in Google Authenticator, Authy, and similar apps.

How to use it

Common uses

Things to keep in mind

A TOTP code is only valid for a short window (usually 30 seconds) — that time limit is the main protection, not the secret alone.

Code accuracy depends directly on the device's clock being synced; a noticeable clock drift is the most common cause of rejected 2FA codes.

Article about this tool: TOTP: how one-time codes in authenticator apps work

Frequently asked questions

Why does my generated code expire so quickly?

TOTP codes are time-based — by default they rotate every 30 seconds, calculated from the current Unix time and the shared secret. This short window limits how long a leaked code stays useful.

What happens if my device's clock is out of sync?

TOTP relies on both sides agreeing closely on the current time. Most authenticator apps and servers allow a small clock drift tolerance (typically one time step), but larger drift will cause valid codes to be rejected.

Is my secret key sent anywhere when generating a code here?

No. The TOTP code is computed entirely in your browser — the secret key never leaves your device.

Does TOTP protect against phishing?

Not entirely. If a victim enters their password and current TOTP code on a fake site, an attacker can instantly use both values on the real site while the code is still valid. Only hardware keys following the FIDO2/WebAuthn standard protect against this kind of real-time attack.

Why does the server also accept the previous time step, not just the current one?

This compensates for a small amount of network delay between generating the code on a phone and the server receiving and checking it. Without this tolerance, legitimate codes would occasionally be rejected due to an ordinary delay of a few seconds.

Articles: Hashes/Crypto

Hash Generator: how MD5, SHA-1, and SHA-256 differ from each other

Why MD5 is still used to verify file integrity, but not for passwords.

Checksum Verifier: how to check that a file isn't corrupted

Why a matching checksum confirms a file's integrity, but not who created it.

HMAC: how a keyed hash differs from a regular hash

Why a plain SHA-256 doesn't protect against message tampering, but HMAC does.

Bcrypt: why passwords are hashed slowly, not quickly

Why fast SHA-256 is a bad choice for passwords, and slow bcrypt is the right one.

UUID: how identifiers that almost never repeat are generated

Why UUID v4 can be generated independently on millions of machines without collision risk.

Password Generator: what actually makes a password strong

Why a long dictionary-word password is stronger than a short one with symbols and digits.

AES: how symmetric encryption works

Why the same key both encrypts and decrypts data in AES, and how that differs from asymmetric encryption.

Argon2: why this algorithm won the password hashing competition

How Argon2 defends better against GPU-based attacks than older password hashing algorithms.

Scrypt: why the algorithm needs so much memory

Why scrypt deliberately demands a lot of memory to make cracking on ASIC devices harder.

PBKDF2: the oldest key-stretching standard

Why the recommended PBKDF2 iteration count keeps growing every year.

X.509: what's inside an SSL certificate

What exactly the browser checks in a site's certificate before showing the green padlock.

PGP: how public-key and private-key encryption works

Why you can freely share a PGP public key but never the private one.