b2KIT

HOTP Counter-Based Code Generator

Generate HOTP (HMAC-based One-Time Password) codes with counter-based increments per RFC 4226.

Tested tool guide Tested browser tools Checked August 16, 2026

What HOTP Counter-Based Code Generator does, with a checked example

An event number selects every result from the HOTP Counter-Based Code Generator. Supply the shared secret and counter value to calculate the RFC 4226 one-time password for that exact state. HOTP calculates HMAC-SHA-1 over an 8-byte representation of the counter, then turns a truncated portion of the result into decimal digits. The usual surprise is that waiting does nothing: unlike TOTP, an HOTP code stays reproducible until the counter advances, and a verifier with a different counter will reject it.

Worked example

A concrete input and expected output from the current implementation.

Input

Base32 secret: GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ
Counter: 0
Digits: 6

Expected output

755224

The Base32 value represents the 20 ASCII bytes 12345678901234567890. For counter 0, dynamic truncation produces 1,284,755,224; reducing it modulo 1,000,000 gives 755224.

How the result is produced

1

RFC 4226 calculation

RFC 4226 encodes the counter as an unsigned 8-byte big-endian value and calculates HMAC-SHA-1 over it using the shared secret. Dynamic truncation derives an offset from the last HMAC byte, reads four consecutive bytes, and clears the highest bit to obtain a 31-bit integer. Taking that integer modulo 10^d and padding with leading zeroes produces a d-digit code.

2

Counter state

With the secret, counter, and digit length held constant, HOTP is deterministic: repeated generation returns the same code. The value changes only when the counter changes, not as time passes. Incrementing is therefore state management, not a source of randomness. This generator can calculate a supplied counter value, but it cannot discover which counter a remote verifier currently expects.

Good uses

  • Checking an HOTP implementation against RFC 4226's published secret, counter, and code test vectors.
  • Reproducing a token code during integration debugging when both systems' shared secret and expected counter are known.
  • Generating the next counter-based login code for a test account provisioned with HOTP, without waiting for a time interval.

Limits and checks

  • Secret encoding is part of the input. Base32 decoding and treating the same characters as literal text create different key bytes and therefore different codes.
  • A correct result for a supplied counter does not reveal the counter expected by the verifier. Counter windows and resynchronization policies are external to this calculation.
  • Leading zeroes are significant. Copy the entire fixed-width code; a verifier may also reject a mathematically correct code if its counter was already used.

Common questions

Why does this code differ from my authenticator?

First check whether the account uses HOTP rather than TOTP. Then match the decoded secret bytes, counter, and digit count exactly. HOTP is deterministic, so any mismatch in those inputs changes the result. If all visible settings match, the authenticator or verifier may have already advanced its counter; this generator cannot infer or resynchronize that remote state.

Does generating a code prove that the secret and counter will be accepted?

No. The result shows only what RFC 4226 produces for the supplied values. Acceptance requires a verifier with the same secret and an allowed counter position, and it may reject a previously used code. The calculation occurs in the browser and is not uploaded by this tool, but the secret remains sensitive wherever you copy, store, or display it.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools