VoriTools

TOTP and HOTP Generator

Use a test Base32 secret to compare authenticator settings and generated codes. Choose TOTP for a clock-based code or HOTP for a specified counter.

Runs locally in your browser
View category: Security & Cryptography (30)
Secrets and one-time codes stay in this browser. Use test secrets whenever possible and never share a live authentication seed.
Authenticator settingsRFC 4226 / RFC 6238 parameters
Parameter review
  • Choose parameters and calculate a code to review the authenticator setup.

Test provisioning before enabling 2FA

Compare the generated value with your implementation using a disposable test secret. Clock drift, secret storage, recovery codes, rate limits, and account recovery still require server-side controls.

How to generate a TOTP or HOTP code

This workbench turns a Base32 secret into the one-time code an authenticator app would show, using the algorithm, digit count and period or counter you select. It also prints the otpauth:// provisioning URI that a QR code would carry.

The HMAC is computed in the tab with Web Crypto. The tool itself sends no request while it works, so the secret and the generated code stay in the browser.

  1. Paste the Base32 secret, or press Generate test secret for a random 160-bit one. Lowercase letters, spaces and the = padding are ignored, so a secret copied out of a server config works as it is.
  2. Choose the mode. TOTP counts time steps — pick the period, where 30 seconds is the default and the most widely supported. HOTP counts events — type the counter value the verifying server is at.
  3. Match the hash and the digit count to what your server verifies (SHA-1 with 6 digits is the common default), then press Calculate code. Load RFC example fills in the RFC 4226 test secret with counter 0.
  4. Read the parameter review: it repeats the decoded secret size, the counter in use and the digit count, and it flags a secret under 20 bytes, a period other than 30 seconds, and HOTP counter handling.
  5. Copy the code for a quick comparison, or copy the otpauth:// URI to configure an app. In TOTP mode the code recalculates at every time step; Clear returns every field to its default.

What the code is, and where the limits are

RFC 4226 and RFC 6238 in one form

The code is an HMAC over the counter in use: the counter is signed with the secret, the last byte of the signature selects a 4-byte window (dynamic truncation), and that value is reduced modulo 10^digits. TOTP is the same function with the counter taken from Unix time divided by the period, which is why a TOTP code changes on its own while an HOTP code waits for the next counter.

The tool matches the published test vectors. With the RFC secret, HOTP counters 0 to 5 return 755224, 287082, 359152, 969429, 338314 and 254676. A clock inside the RFC time step that contains T=59 returns 94287082 with SHA-1 and 8 digits, and the later vectors (T=1111111109 and T=20000000000) return 07081804 and 65353130.

What the parameter review can and cannot tell you

The review restates the parameters that were used and repeats two server-side duties: an HOTP counter has to be incremented and stored atomically by the verifier, and a secret with fewer than 20 decoded bytes is too short for production use. A period other than 30 seconds and SHA-256 or SHA-512 are valid, but fewer apps and servers accept them.

Nothing here validates a code that someone typed in, measures clock drift on the server, or proves that the secret is the one your account uses. Compare a generated code with the implementation that will verify it, and treat the enrolment flow of the authenticator as the source of truth.

Local processing and the provisioning URI

The URI follows the otpauth:// key format — secret, issuer, algorithm (SHA1, SHA256 or SHA512), digits, and period or counter — which is the string a QR code encodes. The secret is written back in Base32 without spaces or padding, and the label joins the issuer and the account name.

The HMAC and the URI are produced inside the tab and the tool sends no request, so the secret and the resulting code never leave the browser. Use a disposable test secret while comparing implementations, and keep production seeds in the systems that are allowed to store them.

Recent tools: