Skip to content
Advertisement

TOTP Generator

Turn an authenticator secret or otpauth QR code into live one-time passwords, with a 30-second countdown and one-click copy.

Generator Crypto

Input

Enter a secret or an otpauth:// URI to start generating codes.

Settings

These apply when you enter a bare secret. An otpauth:// URI carries its own algorithm, digits, and period, which always take precedence.

Digits
Period (seconds)
Everything runs locally — the secret and the codes it produces never leave your browser.

How TOTP Generator works

A time-based one-time password (TOTP, RFC 6238) is a truncated HMAC of the current time computed with a shared secret. Both your authenticator and the server hold the same secret, both look at the same clock, and both therefore derive the same six digits without ever exchanging them.

The counter is Unix time divided by the time step — 30 seconds by default — truncated to an integer, so it advances once every step. That counter is packed into an 8-byte big-endian value and passed through HMAC-SHA-1 (or SHA-256/SHA-512) keyed with the secret, which yields a 20-byte digest.

Dynamic truncation then reduces the digest to a number: the low four bits of the last byte give an offset, four bytes are read starting at that offset, the top bit is masked off to avoid sign issues, and the result is taken modulo 10^6 to produce six digits. That masking step is why TOTP codes are the same length regardless of hash algorithm.

The secret is normally exchanged as a Base32 string or embedded in an otpauth:// URL inside an enrolment QR code. Because verification depends only on a shared clock, servers usually accept the previous and next window too, tolerating about ±30 seconds of drift.

Reference

  • T = floor((unix_time − T0) / X) where T0 = 0 and X = 30 s
  • TOTP = HOTP(secret, T)
  • HOTP(K, C) = truncate(HMAC-SHA-1(K, C)) mod 10^digits
  • otpauth://totp/<issuer>:<account>?secret=<base32>&issuer=<issuer>&period=30&digits=6

How to use this generator

  1. Supply the secret

    Paste the Base32 secret from your provider, or scan the otpauth:// enrolment QR code to fill every parameter at once.

  2. Confirm the parameters

    Check the period, digit count, and hash algorithm match what the service expects. Six digits, 30 seconds, and SHA-1 are the near-universal defaults.

  3. Read the current code

    The code and its countdown update live. Copy it with one click while the timer still has a few seconds left.

  4. Verify against the service

    Enter the code to confirm enrolment worked before you rely on it, and store the secret somewhere you can recover it.

Worked examples

The RFC 6238 reference vector

Given
Secret 12345678901234567890 (ASCII) at Unix time 59, SHA-1, 8 digits
Result
94287082

This is the first test vector in the RFC. Matching it is how implementations prove their truncation and counter handling are correct.

Enrolling from a QR code

Given
otpauth://totp/GitHub:alice?secret=JBSWY3DPEHPK3PXP&issuer=GitHub
Result
A live six-digit code refreshing every 30 seconds

Every parameter — issuer, account, period, digits — comes from the URL, so there is nothing to configure by hand.

Diagnosing a rejected code

Given
A code that the service says is invalid, generated from a correct secret
Result
Local clock is 90 seconds fast

Servers typically accept one window either side. Drift beyond about 30 seconds pushes you outside that tolerance — fix the clock, not the secret.

When to use it

  • Verifying that a newly issued secret actually produces the codes a service expects, before you lose access to the enrolment screen.
  • Recovering access when your authenticator app is on a phone you no longer have but whose backed-up secret you kept.
  • Testing a TOTP implementation you are building against the RFC 6238 reference vectors.
  • Reading codes on a desktop during development without reaching for a phone on every login.
  • Migrating secrets between authenticator apps that offer no export path of their own.

Things to watch out for

  • Anyone holding the secret can generate valid codes forever. Treat it exactly as you would a password, and delete screenshots of enrolment QR codes once enrolment is confirmed.
  • Generating codes in the same browser you log in from removes the second factor’s independence. This is a recovery and testing tool, not a replacement for a separate authenticator device.
  • Codes depend on your system clock. A device more than about a minute out of sync will produce codes every server rejects.
  • Base32 secrets ignore case and padding, but not stray characters. Strip any spaces your provider added for readability if a secret is rejected.

Frequently asked questions

Is my secret sent anywhere?

No. HMAC and truncation run entirely in your browser and the secret is never transmitted or persisted to a server. It lives only in the page while the tab is open.

Why is my code rejected even though the secret is right?

Almost always clock drift. TOTP derives the code from the current time, and servers accept only a narrow window either side of their own clock. Enable automatic time synchronisation on your device and try again.

What is the difference between TOTP and HOTP?

They share the same truncation algorithm. HOTP (RFC 4226) increments a counter on each use, so codes stay valid until used; TOTP (RFC 6238) derives that counter from the clock, so codes expire on a fixed schedule regardless of use.

Can I use this as my everyday authenticator?

You can, but you should not. A second factor is only meaningful if it is independent of the device and browser you authenticate from. Use a dedicated app or hardware key day to day, and this tool for recovery, verification, and development.

Which hash algorithm should I choose?

SHA-1, unless the service explicitly says otherwise. Despite SHA-1 being unsuitable for collision resistance elsewhere, HMAC-SHA-1 remains sound here, and it is what almost every provider implements.

Why do some services use 8 digits or a 60-second period?

Both are permitted by the RFC. Eight digits raise the cost of guessing; a longer period tolerates worse clock drift at the cost of a longer window for a stolen code. Match whatever the service specifies or verification will fail.

Related Developers tools

All developer tools