Generate HMAC-based One-Time Password codes from a secret key and counter value for two-factor authentication.
HOTP Code Generator turns a shared secret and an explicit counter into the decimal passcode defined by HOTP. It applies HMAC-SHA-1 to an eight-byte counter, dynamically truncates the result, and formats the requested number of digits. The counter is event based, not a timestamp: a correct secret still produces the wrong code when the generator and verifier use different counter values. Because the secret is an authentication credential, enter it only on a trusted device. The calculation runs in the browser, and the secret is not uploaded.
A concrete input and expected output from the current implementation.
Input
Secret (Base32): GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ Counter: 0 Digits: 6
Expected output
755224
The Base32 text decodes to the 20 ASCII bytes 12345678901234567890, the shared secret used in the RFC 4226 test vectors. Dynamic truncation produces 1,284,755,224 for counter 0, and reducing that value modulo 1,000,000 gives 755224.
RFC 4226 represents the counter as an unsigned 64-bit value in network byte order. HOTP computes HMAC-SHA-1 using the secret key bytes as the HMAC key and those eight counter bytes as the message. Counter 1 therefore means the eight-byte value 0000000000000001, not the text character "1".
The low four bits of the final HMAC byte select an offset. Four bytes beginning at that offset are converted into a nonnegative 31-bit integer. Taking that integer modulo 10^d yields a d-digit HOTP code, with leading zeroes added when necessary. For the six-digit setting used in the example, the modulus is 1,000,000.
No. HOTP uses an explicit moving counter that advances with token events. TOTP derives its moving factor from fixed time steps, so clock agreement matters there instead of agreement on a stored event counter. Although TOTP applies the HOTP calculation to its time-derived value, HOTP and TOTP credentials are not interchangeable during ordinary enrollment.
The calculation is deterministic, so the same secret, counter, and digit length produce the same code every time. That does not guarantee the code can authenticate twice. A verifier commonly records counter progress and rejects a code associated with an already accepted counter. Follow the counter advancement and resynchronization rules of the system receiving the code.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.