TOTP Generator

The six digits in two-factor authentication are not random and do not come from the server. They are computed from the secret stored on your phone plus the current time, so any device holding the same secret and parameters produces the same code in the same second. This tool runs the formula in your browser: enter the secret and the code matches your phone authenticator.

How the code is computed

• Shared secret: the Base32 string from enrollment, such as JBSWY3DPEHPK3PXP, stored once by the site and once on your device
• Time factor: Unix seconds divided by the period, 30 by default and rounded down, giving a counter that increments every 30 seconds
• HMAC-SHA1: key the secret with that 8-byte big-endian counter to get a 20-byte digest
• Dynamic truncation: take the low 4 bits of the last digest byte as an offset, read 4 bytes from there and clear the top bit for a 31-bit integer
• Modulo: reduce modulo 10^digits, so six digits means mod 1000000, padded with leading zeros
• The server does the same: it recomputes with its own clock and usually accepts one period before or after to absorb clock differences

What the page does

• TOTP codes: multiple account cards, codes masked except the last three digits, tap to reveal for 10 seconds, tap the card to copy
• Time factor panel: live Unix seconds, current counter and remaining seconds with a ring and bar that reset each period. Timing is computed from the absolute timestamp rather than accumulated ticks, so switching tabs or waking from sleep stays aligned
• HOTP counter: enter a counter to generate a code, increment and remember it to simulate an event-based token, or list 10 consecutive codes to check RFC 4226 appendix D
• Code lookup: paste the six digits shown on your phone and search one or two periods before and after across accounts. A hit in the previous period means your computer clock is fast, the next period means slow, and no hit usually means a different secret
• otpauth links: paste otpauth://totp/... to add an account, or export an account link to your phone; parsing URL-decodes automatically, tolerates surrounding text and warns about non-SHA-1 parameters
• Random secrets: 16, 20 or 32 characters (80, 128 or 160 bit) from crypto.getRandomValues, useful when building your own site
• Standard vectors: built-in RFC 6238 appendix B and RFC 4226 tables compare this page against expected values row by row
• Local accounts: stored in localStorage with edit, reorder, confirm-to-delete and clear-all support

Parameter reference

Common questions

• Why does my code differ from the phone? Check four things in order: a copied or missed secret character (Base32 has no 0, 1, 8 or 9, and O read as 0 is common), mismatched digits or period, a drifting clock, and whether the site uses a non-SHA-1 algorithm. Code lookup here separates the first three
• Why Base32 rather than Base64? Secrets get copied by hand or read aloud, so Base32 uses 32 unconfusing uppercase letters and digits, drops look-alikes such as 0O1IL and avoids escaped + / = characters. Spaces, hyphens, line breaks and = padding are normalized before decoding, and invalid characters are reported with their position
• Can it replace a phone authenticator? It computes codes but has no system notifications, encrypted storage or multi-device sync, and clearing browser data loses accounts. Treat it as a debugging and emergency backup while keeping your main authenticator and an offline copy of the secret
• Is the secret uploaded? No. SHA-1, HMAC-SHA1 and Base32 are implemented in page JavaScript, not crypto.subtle, and no requests are sent; it works offline or on a plain http intranet page, and accounts stay in this browser
• How do I back up accounts? Copy each otpauth link into a password manager note, or export links and store them safely. The secret is plain text, so protect it like a password
• Is TOTP better than SMS? Codes are generated locally and do not depend on a carrier, so SIM swaps, SMS interception and signal coverage do not matter. The tradeoff is that a lost secret cannot be recovered by identity checks, so keep recovery codes
• Can repeated wrong codes lock me out? Lockout is server side and unrelated to this page. If codes get worse over time, check the clock first, then confirm the account is not HOTP used as TOTP
• Is HOTP still used? Hardware tokens and some legacy systems use it. It increments a counter on each use, so both sides must stay in sync and must be re-paired when they drift, which is why time-based systems use TOTP
• Can the RFC 6238 sample secret be used on a real account? No. The test secret 12345678901234567890, Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, is published in the standard, so anyone can compute its codes; it only verifies an implementation

All computation runs locally in the browser and the secret is never uploaded.