TOTP Generator and 2FA Code Checker
Generate and verify six-digit 2FA codes from a Base32 secret or otpauth URI (RFC 6238), see previous and next codes, and make a new secret with a QR code.
The interactive tool loads here when JavaScript runs.
About this toolWhat is the TOTP Generator?
Paste a Base32 secret, or a whole otpauth:// link from a 2FA QR code, and this tool shows the current one-time code with a countdown to the next one, plus the previous and next codes either side. It follows RFC 6238 (TOTP) and RFC 4226 (HOTP), the same algorithms that Google Authenticator, Microsoft Authenticator, Authy, 1Password and hardware tokens implement, so the code here should match the one on your phone.
It also works the other way round. Type a code into the checker to see whether it is valid now, one step behind or one step ahead, which is the quickest way to tell a wrong secret from a phone whose clock has drifted. Developers adding two-factor login can generate a fresh 160-bit secret, copy the otpauth URI, scan the QR code with a real app and confirm both sides agree before writing any server code.
All of it runs in your browser with Web Crypto. The secret, the codes and the QR image stay on your device.
- RFC 6238 TOTP and RFC 4226 HOTP with SHA-1, SHA-256 and SHA-512
- 6, 7 or 8 digits and any period
- Live code with countdown plus previous and next codes
- Code checker with a configurable drift window
- otpauth:// URI parser and builder
- Random 160-bit secrets and a scannable QR code (PNG download)
- Clock offset to simulate a fast or slow device
How to use the TOTP Generator
- Paste an otpauth:// URI to fill everything in, or type the Base32 secret shown under "can't scan the code?" on the service's setup page.
- Leave algorithm, digits and period at SHA-1, 6 and 30 unless the service says otherwise.
- Read the current code and the countdown. Click the code to copy it.
- To diagnose a failing login, type the code your app shows into "Check a code". The result says whether it matches now, one step behind or ahead.
- To set up a new account in your own app, press New for a random secret, set the issuer and account, and scan the QR code with an authenticator.
Worked examples
RFC 6238 test vector
Input
Secret ASCII "12345678901234567890" (Base32 GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ), SHA-1, 8 digits, time 59
Output
94287082
Time 59 is step 1. This is the first row of Appendix B and the tool's own test suite checks every row for SHA-1, SHA-256 and SHA-512.
Clock drift diagnosis
Input
Code from the phone entered 40 seconds after it appeared
Output
Valid 1 step behind
The code belongs to the previous 30-second window. A server with a one-step window still accepts it; a strict server would not, so check the phone uses network time.
Reading a QR payload
Input
otpauth://totp/ACME%20Co:john@example.com?secret=HXDMVJECJJWSRB3HWIZR4IFUGFTMXBOZ&issuer=ACME%20Co
Output
Issuer ACME Co, account john@example.com, 160-bit secret, SHA-1, 6 digits, 30 s
Missing parameters take the format's defaults. The issuer in the label and the issuer parameter should agree.
Background and insight
HOTP, published as RFC 4226 in 2005, turns a shared secret K and a counter C into a short code: compute HMAC-SHA1(K, C) with the counter as 8 big-endian bytes, take the low 4 bits of the last byte as an offset, read 4 bytes from that offset, clear the top bit, and keep the last 6 to 8 decimal digits. TOTP, RFC 6238 from 2011, replaces the counter with the number of 30-second steps since the Unix epoch, T = floor((now − T0) / X), with T0 = 0 and X = 30 by default. It also allows HMAC-SHA256 and HMAC-SHA512.
Because the code depends on the time, server and phone must agree on the clock. RFC 6238 section 5.2 suggests accepting at most one step of drift either side, and section 5.3 suggests the server remember drift it has seen. A code is therefore usually accepted for up to about 90 seconds, and a server should also reject a code that has already been used once.
Secrets travel in the Key URI Format that Google documented for Authenticator: otpauth://totp/Issuer:account?secret=BASE32&issuer=Issuer&algorithm=SHA1&digits=6&period=30. The secret is RFC 4648 Base32 (letters A to Z and digits 2 to 7). RFC 4226 requires a shared secret of at least 128 bits and recommends 160, which is 32 Base32 characters. The Key URI Format notes say some apps ignore the algorithm, digits and period parameters, which is why almost every service sticks to SHA-1, 6 digits and 30 seconds.
Common use cases
Building 2FA into an app
Generate a secret and URI, scan it with a real authenticator, and use the code list to test your server's verification and drift window.
Debugging rejected codes
Tell a wrong secret from clock skew by checking which step a code belongs to.
Automated test accounts
Read the code for a test account's secret during manual QA without reaching for a phone.
Migrating authenticators
Check that a secret exported from one app produces the same codes before deleting the old entry.
Tips and limitations
- A TOTP secret is as sensitive as a password: anyone holding it can produce valid codes. Use this page for test and development secrets, and keep real ones in an authenticator app.
- If every code is rejected, the secret or algorithm is wrong. If codes work sometimes, look at the clock: phones on manual time are the usual cause.
- Base32 has no 0, 1, 8 or 9. A secret containing them was mistyped or is in another encoding such as hex.
- Store secrets on the server encrypted, and mark each accepted time step as used so the same code cannot log in twice.
- Offer recovery codes alongside TOTP. Users lose phones far more often than attackers break HMAC.
Frequently asked questions
Why is my authenticator code being rejected?
The two common causes are a clock that is more than about 30 seconds off and a secret that was copied wrongly. Enter the code from your app in the checker: if it matches one step behind or ahead, fix the clock; if it never matches, re-enrol with a fresh QR code.
How long is a TOTP code valid?
Each code belongs to one 30-second step. Most servers also accept the step before and after to allow for drift, so in practice a code works for between 30 and 90 seconds, and it should only be accepted once.
What is the difference between HOTP and TOTP?
HOTP uses a counter that goes up each time a code is generated, so codes stay valid until used. TOTP uses the current time step instead, so codes expire automatically. Both use the same HMAC truncation from RFC 4226.
What is in an otpauth URI?
The type (totp or hotp), a label with issuer and account, and parameters: secret in Base32, issuer, algorithm, digits, and either period for TOTP or counter for HOTP. Defaults are SHA1, 6 digits and 30 seconds.
Can I use SHA-256 or 8 digits?
RFC 6238 allows both, and this tool supports them. Several popular apps ignore those parameters and always use SHA-1 with 6 digits, so test the first code from the app before you enforce non-default settings.
Is HMAC-SHA1 still safe for 2FA codes?
Yes. The collision attacks on SHA-1 do not affect HMAC-SHA1 as used in HOTP and TOTP, and RFC 6238 keeps SHA-1 as the default. The weak points in practice are phishing and stolen secrets, not the hash.
How long should a TOTP secret be?
RFC 4226 requires at least 128 bits and recommends 160 bits, which is 20 random bytes or 32 Base32 characters. The New button here creates a 160-bit secret from the browser's cryptographic random number generator.
Is there an in-depth guide to the TOTP Generator?
Yes. “How TOTP 2FA Codes Work: RFC 6238 Step by Step” covers the background, how it works, common pitfalls and worked examples. Read the full guide.
People also search for
- generate totp code from secret key
- why is my 2fa code not working time sync
- otpauth uri format explained
- test google authenticator secret online
- create qr code for 2fa secret
- rfc 6238 test vectors
- hotp vs totp difference
- how many seconds is a totp code valid
Related Tools You May Like
Free, in-browser tools that pair well with this one.