TOTP Calculator
Six or eight digit authenticator codes from a Base32 secret, with every step shown.
What it does
Every authenticator app on your phone runs the same small recipe. It takes a shared secret, mixes it with the current time through HMAC-SHA1, and truncates the digest down to six digits. Because both sides know the secret and the clock, both compute the same code without ever sending it.
The tool above computes RFC 6238 time based one time passwords locally in your browser. Paste the Base32 setup key, choose the code length and step, and read the current code along with the counter and validity window the server uses.
The default secret is the published RFC test key, which at time 59 with 8 digits returns 94287082. Leave the reference time blank and the tool follows your device clock, exactly as an app would.
The recipe comes from RFC 6238, which builds directly on the HMAC based HOTP algorithm of RFC 4226: counter as eight big endian bytes, HMAC-SHA1, dynamic truncation of four bytes, then modulo ten to the digits.
How to use
- Paste the Base32 secret from the account's setup screen.
- Pick 6 digits and a 30 second step unless the service says otherwise.
- Leave the reference time blank to compute from the device clock.
- Press Calculate for the code, counter, and expiry window.
- To verify against the RFC, set 59 seconds, 8 digits, and read 94287082.
Formula
- K
- The shared secret, Base32 decoded to bytes.
- t
- Unix time in seconds.
- step
- Time step in seconds, usually 30.
- code
- The one time password, zero padded to 6 or 8 digits.
RFC 6238 notes SHA-1 remains the interoperable default, and real services force rate limits because a six digit code is guessable if you allow unlimited tries. This page computes everything in your browser; the secret never travels anywhere.
Worked example
Example: the RFC 6238 test vector
Secret GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ, which decodes to the ASCII bytes of 12345678901234567890, reference time 59 seconds, 8 digits.
- T = floor(59 / 30) = 1.
- Counter bytes: seven zeros then 01.
- HMAC-SHA1 digest starts 75a48a19...
- Last digest byte 0x1d has low nibble 11; offset 11 with the top bit masked.
- Truncated value mod 100,000,000 gives 94287082.
- The same secret at time 0 gives 755224 with 6 digits.
Reference table
| Time (s) | Counter T | 8 digit code |
|---|---|---|
| 59 | 1 | 94287082 |
| 1111111109 | 37037036 | 07081804 |
| 1111111111 | 37037037 | 14050471 |
| 1234567890 | 41152263 | 89005924 |
| 2000000000 | 66666666 | 69279037 |
| 20000000000 | 666666666 | 65353130 |
Limits
- SHA-1 only, as the standard specifies.
- Clock drift beyond one step breaks codes.
- Not a substitute for a hardened authenticator.
- Never log or share the secret.
Common mistakes
- Pasting the QR image instead of the text key.
- Using a secret shorter than 10 bytes.
- Expecting a code to survive a step boundary.
- Trusting a device clock that drifts minutes per day.
- Testing with real secrets on a shared machine.
Try it yourself
Quick checks. Answers sit tucked under each question.
Secret GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ at 30 s, 6 digits?
287082, counter T = 1.
Same secret at 0 s?
755224 from HOTP counter 0.
Why does the code change mid typing?
The step rolled over; re-enter on the fresh window.
Questions
Is this safe to use with real secrets?
The math runs in your browser and nothing is sent anywhere, but treat any web page touching your secret with caution; prefer your phone for production accounts.
Why does my authenticator differ?
Check the digits and period settings; some services use 8 digits or a 60 second step, and a clock drift of a minute breaks the match.
What is the counter T?
The number of time steps since the Unix epoch, floor of time divided by step; it is what HOTP hashes.
Why does the code have leading zeros sometimes?
The digest modulo ten to the digits can start with zero; authenticators always zero pad.
Can codes be replayed?
Within the validity window yes, which is why servers enforce one use and rate limits.
Why SHA-1 still?
HMAC-SHA1 remains secure for this construction and keeps every authenticator interoperable; RFC 6238 also lists SHA-256 and SHA-512 variants.