TOTP Generator

You are locked out of a staging environment because your phone died, your QA team needs predictable two-factor codes for automated login tests, or you are migrating a self-hosted authenticator and need the raw secret rendered as working codes. This generator turns any Base32 shared secret into the live time-based one-time passwords that RFC 6238 defines, with the same algorithm Google Authenticator, Authy, and 1Password use.

Paste a secret, watch the current code update every step, and verify any candidate code against the same secret with a configurable clock-skew window. The HMAC work happens through the Web Crypto API inside your tab, so the secret never leaves the machine.

How TOTP generation works under the hood

TOTP is HOTP (RFC 4226) with the moving factor swapped from a counter to the clock. The shared secret is decoded from Base32 into raw key bytes, then the current step counter is computed as the floor of Unix epoch seconds divided by the period, minus the optional t0 epoch from the RFC (zero in practice). That counter is serialized as an unsigned 8-byte big-endian integer and used as the message in an HMAC over the key.

The truncation step takes the last byte of the HMAC digest as a four-byte offset into the digest, clears its high bit to force a positive 31-bit integer, and reduces that number modulo one million (for six digits) or one hundred million (for eight). Modulo is what introduces the slight non-uniformity of leading zeros, which is why some banks dislike very small codes; it has no practical effect on security given the secret entropy.

Servers usually accept codes from the previous, current, and next step so that modest clock drift does not lock users out. The verify panel in this tool applies exactly that window, which is also why a code you saved thirty seconds ago can still validate while the countdown shows a new step has begun.

Before and after: RFC 6238 test vector

Input — the SHA1 test vector from RFC 6238 Appendix B:

secret (ASCII):  12345678901234567890
secret (Base32): GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ
time:            59 seconds after epoch
period:          30
digits:          8
algorithm:       SHA1

Output:

counter: floor(59 / 30) = 1
code:    94287082
the same secret with SHA256 at the same instant yields 46119246,
which is why the algorithm selector must match the issuer config

Press Load RFC test secret above and the generator reproduces 94287082 only if you also set the time back to the vector instant, but the verify panel accepts it with a widened window from any modern clock for demonstration.

Who uses this generator

Common mistakes when generating TOTP codes

• Pasting a Base64 or hex string into the secret field. Authenticator seeds are Base32 (A-Z, 2-7). A Base64 secret contains characters like lowercase letters mixed with numbers 0, 1, 8, and 9 that do not exist in Base32, and the generator will reject them rather than produce codes that silently fail at the server.
• Mismatching the digits setting. A server expecting eight digits will reject every six-digit code you submit, even though the underlying HMAC matches. Check the vendor documentation or the otpauth URI parameter rather than assuming six.
• Ignoring clock drift on servers. If a virtual machine clock is minutes off, no code will ever validate because the step counter is computed from wall-clock time. Compare the counter line shown here with the server clock before rotating secrets unnecessarily.
• Using the password, not the seed. The string in your password manager entry labeled password is usually a backup code or the account password. The TOTP seed is the Base32 string shown at enrollment time, often grouped in fours and sometimes hidden behind a reveal control.

Best practices for handling TOTP secrets

• 1.Store enrollment secrets in the same secrets manager you already trust for API keys, encrypted at rest, with access logged, so break-glass recovery does not depend on a single phone.
• 2.Prefer SHA256 or SHA512 when the identity provider exposes the choice, and record the algorithm next to the secret; half of all failed migrations come from an unstated SHA1 default.
• 3.Give automated test fixtures a fixed timestamp rather than reading the wall clock, which turns flaky time-dependent assertions into deterministic ones.
• 4.Pair TOTP with single-sign-on or hardware keys for privileged accounts; time-based codes phish as easily as passwords when a fake login page relays them in real time.

Frequently asked questions