TOTP Code Generator & Checker
Make the 6- or 8-digit codes an authenticator app shows from a Base32 secret, check a typed code against the current and neighbouring windows, and build the otpauth:// QR code.
How to Use
- Paste a Base32 secret (the “setup key” a site shows next to its QR code), or press New random secret to make one.
- Match the settings to the service: almost all use SHA-1, 6 digits, 30 seconds.
- Read the live code in the ring. It changes when the ring empties; the previous and next codes are listed beside it.
- To test a server or an app, type a code into Check a code. The page tries the current window and one either side and says which one matched.
- Choose Fixed time and enter a Unix time to reproduce the RFC 6238 test vectors, or any moment in the past or future.
- Add an issuer and account name to build the
otpauth://URI and its QR code, ready to scan into an authenticator app.
—
Worked Example
The first test vector in RFC 6238: the secret is the 20 ASCII bytes “12345678901234567890”, written in Base32 as GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ. SHA-1, 8 digits, 30-second period, Unix time 59.
1. Counter: T = ⌊59 / 30⌋ = 1, written as 8 bytes: 00 00 00 00 00 00 00 01.
2. HMAC-SHA1(secret, counter) = 75a48a19d4cbe100644e8ac1397eea747a2d33ab (20 bytes).
3. Offset: the last byte is ab; ab & 0f = b = 11.
4. Bytes 11 to 14 are c1 39 7e ea. Clearing the top bit gives 0x41397eea = 1,094,287,082.
5. 1,094,287,082 mod 108 = 94287082, the value in the RFC. With 6 digits it is mod 106 = 287082.
At T = 1111111109 the same secret gives 07081804: the code is a number padded to 8 digits, so a leading zero is part of it.
The common mistake: using the Base32 text itself as the key. HMAC over the 32 ASCII characters “GEZD…QOJQ” instead of the 20 bytes they encode gives 58372946 at T = 59, not 94287082. The second classic is passing milliseconds: 59,000 / 30 makes the counter 1,966 instead of 1 and the code 75954331.
Show Work
Formulas
From Key-Fob Tokens to Authenticator Apps
One-time passwords long came from proprietary hardware tokens with their own secret algorithms. The Initiative for Open Authentication (OATH) published an open one, HOTP, as RFC 4226 in December 2005: HMAC-SHA1 of an 8-byte counter, cut down to 6 to 8 digits by “dynamic truncation”. A counter that both sides must keep in step is awkward, so RFC 6238 (May 2011) defined TOTP, which takes the counter from the clock instead and adds SHA-256 and SHA-512 options.
Google Authenticator, released in 2010, made TOTP an everyday thing and popularised the otpauth:// URI inside a QR code, so setting up an account became a single scan. Because the code depends only on the shared secret and the time, an authenticator app needs no network connection; the same property means anyone who copies the secret can make valid codes, which is why sites show it only once.
About This Tool
This tool produces RFC 6238 time-based one-time passwords from a Base32 secret with SHA-1, SHA-256 or SHA-512, 6 or 8 digits and a 30- or 60-second period. It shows the live code with a countdown, the codes either side, checks a typed code against all three windows, and can freeze time at any Unix second to reproduce the RFC test vectors.
The HMAC and hash functions are this page’s own JavaScript and the QR code is drawn on the page, so everything runs in your browser. The secret is never uploaded, stored or written into the address bar; the live code relies on this device’s clock.
It suits developers adding two-factor login, support staff diagnosing rejected codes, and anyone curious about what an authenticator app does every 30 seconds.
Related tools: HMAC Generator, QR Code Generator, and Unix Timestamp Converter.
Frequently Asked Questions
Why is my authenticator code rejected?
Usually the clock. A TOTP code is worked out from the current time, so a phone or server that is 40 seconds out is already more than one 30-second window away. Most servers accept the window before and after the current one (90 seconds in total) for that reason. If the clock is right, check the settings: a code made with 8 digits, a 60-second period or SHA-256 will never match one made with the defaults.
What is the difference between TOTP and HOTP?
HOTP (RFC 4226, 2005) makes a code from a counter that goes up by one each time you press the button on a token. TOTP (RFC 6238, 2011) uses the same calculation but replaces the counter with the number of 30-second steps since 1 January 1970, so the code changes by itself and the server needs no stored counter. At Unix time 59 the TOTP counter is ⌊59 / 30⌋ = 1.
Is it safe to paste a real secret here?
The page works entirely in your browser: the secret is not uploaded, saved or put in the address bar, and the QR code is drawn on the page. Still, the secret is the whole second factor — anyone who has it can make your codes — so use test secrets where you can, clear the page afterwards, and never share a screenshot of the QR code.
Why does my app ignore SHA-256, 8 digits or a 60-second period?
The otpauth:// format allows them, but support varies. Google’s own Key URI Format notes said its Authenticator apps ignored the algorithm parameter, and several apps have fallen back to SHA-1, 6 digits and 30 seconds. After scanning, compare the app’s code with this page’s; if they differ, stay with the defaults, which every app supports.
How long should a TOTP secret be?
RFC 4226 requires at least 128 bits (16 bytes) and recommends 160 bits (20 bytes), which is 32 Base32 characters. The RFC 6238 test vectors use 20 bytes for SHA-1, 32 for SHA-256 and 64 for SHA-512, matching each hash’s output size, and the random-secret button follows the same rule.
How do I use the TOTP Code Generator & Checker?
Just pick your options. The answer shows up right away — there is no button to press. Change anything and it updates by itself.
Do I need to install or sign up for anything?
Not at all — it runs in the browser with nothing to install and no account. After it loads once, it even works without an internet connection.
Is my information private?
Yes. Everything happens in your browser. Nothing you type is sent to a server or saved anywhere.
Common Use Cases
Testing a 2FA login
Check your server against RFC 6238: secret “12345678901234567890”, T = 1111111109, SHA-1, 8 digits must give 07081804, leading zero included.
Debugging “invalid code”
Type the rejected code and see whether it belongs to the previous or next window, a sign that the clocks are 30 seconds or more apart.
Adding a test account to an app
Make a random 20-byte secret, scan the QR code and confirm the app shows the same 6 digits as the ring.
Reading a setup key
A key shown as “gezd gnbv gy3t qojq …” in groups of four is Base32; spaces and lower case are ignored, so paste it as it is.
Teaching how 2FA works
Show Work goes from the 8-byte counter to the 20-byte HMAC, the offset, the 31-bit number and the final modulo.
Last updated: