TOTP Generator

TOTP turns a shared secret and clock into a short code

Time-based One-Time Password is specified by RFC 6238 as a time-based form of HOTP. An authenticator and server share secret bytes. Both derive a counter from Unix time, compute an HMAC over that counter, dynamically truncate part of the result, and reduce it to a fixed number of decimal digits. Agreement requires the same secret, algorithm, period, digit count, and sufficiently synchronized clocks.

This TOTP generator online implements HMAC-SHA-1 with either 6 or 8 digits and a 30- or 60-second period. It accepts an RFC 4648 Base32 secret, removes spaces, ignores letter case, and tolerates trailing = padding. The active code updates each second; a bar shows time remaining and turns amber or red near rollover. The displayed space in 123 456 is only for readability, while Copy writes the unspaced digits.

Use the page to test development secrets, diagnose provisioning parameters, and compare an authenticator implementation. A TOTP seed is a long-lived credential, unlike the short code derived from it. Anyone with the seed can generate current and future codes, so never paste a real production account’s Base32 secret into an online tool. Store production seeds encrypted with tightly controlled server-side keys, and protect enrollment as carefully as password reset.

Follow one counter through RFC 6238

At Unix time t, with start time T0 normally zero and period X, the moving factor is:

counter = floor((t - T0) / X)

The counter becomes an 8-byte unsigned big-endian value. This component imports the decoded Base32 bytes as an HMAC-SHA-1 key and signs those eight bytes. The low four bits of the final HMAC byte select an offset. Four bytes beginning there are read with the high sign bit cleared, yielding a 31-bit integer. The final code is integer mod 10^digits, left-padded with zeroes.

Leading zeroes are part of the code. Treat 004219 as a six-character string, not integer 4219. The code is not encryption and Base32 is not encryption. Base32 simply expresses arbitrary seed bytes using uppercase letters A-Z and digits 2-7, avoiding visually and transport-sensitive symbols.

The short decimal space means collisions are expected over time. A six-digit code has one million possibilities, not one million bits of strength. Security relies on a secret seed, brief validity, rate limiting, replay handling, and a protected primary factor.

Work through the controls

Enter a disposable Base32 seed such as the page’s example JBSWY3DPEHPK3PXP. Characters 0, 1, 8, and 9 are invalid in standard Base32 and produce an error. Spaces are removed as typed; lowercase input is normalized for decoding.

Select 6 Digits (Standard) for common authenticator compatibility or 8 Digits only when both provisioning metadata and server require it. Changing digits does not strengthen the underlying seed; it reduces online guessing probability when rate controls are equal, but may be unsupported by an app.

Select 30 Seconds (Default) unless the issuer specifies 60. Period is not a grace window. It defines counter boundaries, so a client using 60 seconds will usually disagree with a 30-second server even at the same wall-clock time. The countdown reflects the browser device clock. If it disagrees with a phone, compare both devices with a trusted time source.

Copy a code away from the final seconds where possible. A network request sent before rollover may be verified after it. Servers commonly accept a small neighboring-step window for clock skew, but broader windows extend replay opportunity and should not compensate for broken time synchronization.

Provisioning and integration workflow

Most authenticator apps receive an otpauth:// URI through a QR code. A typical shape is:

otpauth://totp/Example:[email protected]?secret=BASE32&issuer=Example&algorithm=SHA1&digits=6&period=30

URI labels and query values must be percent-encoded correctly. The secret value carries Base32 text without exposing it beyond enrollment. Issuer and account label help users distinguish entries but do not affect this component’s HMAC calculation. This page does not parse an otpauth URI or scan QR codes; enter only the raw Base32 secret and set digits and period manually.

For implementation tests, use RFC 6238 vectors with a fixed injected clock. Do not assert against the live wall clock in a unit test. Cover the instant before a boundary, the boundary itself, leading-zero output, invalid Base32, lowercase and padded input, six and eight digits, and an adjacent counter. Cross-check with a second independent library.

At enrollment, generate at least 160 random secret bits with a CSPRNG, encode them as Base32, display the provisioning URI over an authenticated TLS session, and require one valid code before enabling TOTP. Never derive the seed from username, password, timestamp, UUID, or an ordinary hash of predictable values. Provide single-use recovery codes generated and stored securely.

At verification, retrieve and decrypt the account seed, calculate expected codes for the configured step and narrowly allowed skew, compare in constant time where the framework permits, apply account and network rate limits, and mark an accepted step to prevent reuse. Return a generic failure rather than revealing whether the password or TOTP failed.

Security properties and limits

TOTP is a possession factor only to the extent that the seed remains on a separate protected device. If password and seed are stored in the same password manager or compromised browser profile, they may still improve resistance to database-only attacks but share a compromise path. TOTP codes are phishable: a reverse proxy can relay a current code immediately and capture the resulting session. Origin-bound passkeys or FIDO2 security keys provide stronger phishing resistance.

Codes are not automatically single-use. During a valid window, the same digits can be submitted repeatedly unless the server records the accepted counter. Enforcing one use per account and step helps, though concurrency and retries need deliberate handling.

SHA-1’s collision weaknesses do not directly break HMAC-SHA-1 in TOTP, and RFC compatibility keeps it common. New provisioning can support SHA-256 or SHA-512 only if authenticator ecosystems do; this specific generator offers SHA-1 only. Never assume a UI’s missing algorithm selector follows URI metadata automatically.

Clock correctness is part of the security boundary. Servers should use reliable time synchronization and alert on drift. Clients generally use system time rather than network calls per code. Do not log submitted codes, seeds, QR payloads, or decrypted enrollment data. Mask secrets in support tooling and audit access.

Interpret the live countdown correctly

The progress bar is derived from the current Unix second modulo the selected period, so it measures the browser clock’s position in the active step rather than querying an issuer. Changing from 30 to 60 seconds immediately changes both the counter and bar width; it does not extend the code that was generated under the previous setting. Invalid or empty Base32 input replaces the digits with dashes and disables copying. When comparing two implementations, record the exact Unix timestamp and selected period instead of comparing whichever values happen to be visible, since testing across a rollover can make correct implementations appear inconsistent.

Frequent causes of “invalid authenticator code”

• Pasting the full otpauth:// URI into a field that expects only Base32.
• Decoding the visible Base32 as UTF-8 text instead of decoding it to key bytes.
• Using little-endian or four-byte counter serialization rather than eight-byte big-endian.
• Selecting 8 digits or 60 seconds on only one side.
• Dropping leading zeroes by parsing the result as a number.
• Authenticating at rollover with excessive device clock drift.
• Re-enrolling a seed on the server while testing an older authenticator entry.
• Confusing HOTP’s event counter with TOTP’s time-derived counter.

FAQ

Why does the TOTP code change while the secret stays the same?

The time counter changes at each period boundary. HMAC input changes, so a new decimal value is derived from the same shared seed.

Can I verify yesterday’s code?

Normally no. Servers accept the current step and perhaps a small adjacent window. A large historical window defeats the time-limited design.

Is a 60-second period more secure?

Not inherently. It halves rollover frequency but leaves each code valid longer. Use the issuer’s exact period and control online attempts.

Why does this generator disagree with Google Authenticator?

Check that you entered only the same Base32 seed and selected SHA-1-compatible parameters, 6 digits, and 30 seconds. Then check both device clocks and whether enrollment was replaced.

Can TOTP replace passwords?

TOTP is usually a second factor, not a durable standalone authenticator. Prefer modern, origin-bound, phishing-resistant passkeys where available and maintain secure recovery paths.