# TOTP / HOTP Generator & Validator > Generate and check time-based (TOTP, RFC 6238) and counter-based (HOTP, RFC 4226) one-time passwords - the codes behind authenticator apps and hardware tokens such as FortiToken. SHA-1/256/512, configurable digits and step. Computed locally with Web Crypto; your secret never leaves your browser. - Tool: https://ronutz.com/en/tools/totp-hotp - Family: Identity & tokens --- ## What it does Generate and verify the one-time codes used for two-factor authentication: time-based passwords (TOTP, RFC 6238), the six-digit codes an authenticator app shows, and counter-based passwords (HOTP, RFC 4226), the codes a hardware token produces. You can choose the hash (SHA-1, SHA-256, or SHA-512), the number of digits, and the time step. The computation uses the browser's native Web Crypto, and your shared secret never leaves your browser. ## One construction, two moving factors HOTP and TOTP are the same algorithm underneath. Both take a shared secret and a moving factor, compute an HMAC of the moving factor under the secret, and then apply the "dynamic truncation" defined in RFC 4226 to reduce that MAC to a short decimal code. The only difference is where the moving factor comes from: - **HOTP** uses an explicit event counter that increments by one each time a code is used. The token and the server have to stay in step on that counter. - **TOTP** uses the clock: the moving factor is the number of time steps since an epoch, `floor((current time - T0) / step)`, with `T0` at 0 and the step 30 seconds by default. In other words, TOTP is simply HOTP whose counter is the current time slice, which is why a TOTP code changes every 30 seconds. ## The shared secret The secret is the seed both sides hold. It is usually exchanged as a Base32 string, which is what an `otpauth://` URI or a setup QR code encodes, so the tool decodes Base32 to recover the key bytes. The default hash is SHA-1, which is what most authenticator apps and tokens still use for one-time passwords; SHA-256 and SHA-512 are available where both sides support them. ## Verification and clock drift Because a device's clock and a server's clock are never perfectly aligned, a TOTP check normally accepts codes from a small window of adjacent time steps rather than only the current one, trading a little strictness for reliability. HOTP has the analogous problem on the counter, where a token can advance if a generated code is not used, so servers accept a look-ahead window and resynchronize. ## Using it Enter the shared secret and generate the current TOTP code, or set a counter to generate a HOTP code, and adjust the hash, digit count, and step to match your system. You can also validate a code you were given. The algorithm is deterministic given the secret and the moving factor, so the same inputs always produce the same code. ## Standards and references - [RFC 6238 - TOTP: Time-Based One-Time Password Algorithm](https://www.rfc-editor.org/rfc/rfc6238) - the TOTP construction and its Appendix B test vectors - [RFC 4226 - HOTP: An HMAC-Based One-Time Password Algorithm](https://www.rfc-editor.org/rfc/rfc4226) - the HOTP construction, dynamic truncation, and Appendix D vectors - [RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://www.rfc-editor.org/rfc/rfc4648) - Base32 decoding of the shared secret ## Related reading - [Base32, explained](https://ronutz.com/en/learn/base32.md): Why Base32 trades size for a case-insensitive, unambiguous alphabet, how its 5-bit grouping works, and where it shows up (TOTP secrets, onion addresses, DNS). - [HMAC: keyed hashing for message authentication](https://ronutz.com/en/learn/hmac.md): Why a plain hash proves integrity but not authenticity, how a secret key fixes that, and why HMAC's structure matters. - [How TOTP and HOTP one-time passwords work](https://ronutz.com/en/learn/totp-and-hotp.md): Both turn a shared secret into a short code that proves possession without sending the secret. HOTP counts events; TOTP counts time. The engine underneath is the same HMAC plus a truncation step. - [Provisioning Authenticators: otpauth URIs and QR Codes](https://ronutz.com/en/learn/totp-provisioning-uris-and-qr.md): Before an authenticator app can generate codes, it needs the shared secret and the parameters that go with it. That is carried in an otpauth URI, usually shown as a QR code to scan. Knowing the URI's fields explains what the QR code actually contains and why the secret is in base32. - [Validating one-time passwords: drift, windows, and replay](https://ronutz.com/en/learn/validating-totp-codes.md): Generating a code is the easy half. Accepting one means tolerating clock drift, bounding the window, rejecting reuse, and throttling guesses, each a tradeoff between usability and security.