TOTP generator
Time-based one-time password (RFC 6238), computed on your device. The secret never leaves your browser.
Runs on your device. The file is never uploaded.
TOTP generator turns a shared secret into a one-time code from the clock, counting 30-second steps since the unix epoch. The defaults follow RFC 6238: base32 input, 6 digits and SHA-1. A time box accepts any non-negative unix value in place of now. The result is the code alone, with no countdown to when it lapses.
Questions
Where does my TOTP secret go?
Nowhere. The secret is decoded and HMACed by crypto.subtle in a Web Worker in this tab. It is not uploaded, not stored and not remembered between runs, so you have to paste it again each time. That is deliberate. This is a way to read one code, not a replacement for an authenticator app that keeps your secrets for you.
What settings do I need to match my authenticator?
The defaults follow RFC 6238 and match most apps: a base32 secret, 6 digits, SHA-1, and a 30-second period. If your codes are wrong but the secret is right, the usual culprits are a digit count of 8 or an algorithm of SHA-256 or SHA-512. The tool offers SHA-1, SHA-256 and SHA-512, and 1 to 10 digits, refusing others with "digits must be a whole number 1-10".
Why does it complain about a character in my secret?
Because base32 uses A to Z and 2 to 7 only, and the tool refuses anything else by name instead of dropping it. Spaces, hyphens and trailing = padding are stripped silently, since printed secrets often carry them. Anything else, most often a 0 typed for O or a 1 typed for I, raises an error naming the character and pointing at 0, 1, 8 and 9. Dropping it silently would give a wrong code with no warning.
Can I generate a code for a time other than now?
Yes. Leave the time option blank for the current clock, or enter a unix time in seconds to generate the code for that moment. It must be a non-negative number, otherwise you get "time must be a non-negative unix timestamp in seconds". This is how you check whether a code failed because the clock on the device that produced it had drifted.
Why is my code rejected by the service?
Most often clock skew or a mismatched setting. The code comes from floor(unix time / period), so if your device clock is off by more than the 30-second window you get a valid code for the wrong step. Try the same secret with the time option set one step earlier or later. Otherwise check the digits, the algorithm and the period against what the service issued.
Can it read a QR code or an otpauth link?
No. It takes the shared secret only, as base32 or as plain text through the format option. If you have an otpauth:// URI, pull the secret parameter out of it yourself, along with any non-default digits, algorithm or period values, and enter them here.