AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I generate a TOTP (2FA) code from a secret in the browser?

Paste your Base32 secret (or generate a random one), pick the algorithm (SHA-1 by default, or SHA-256 / SHA-512), the digits (6 or 8) and the period (usually 30s). The tool computes the standard RFC 6238 code with the browser’s native Web Crypto HMAC and refreshes it live with a countdown ring and a next-code preview. It also builds the otpauth:// key URI and a scannable QR so you can import the secret into Google Authenticator or Authy, and verifies any code with ±1-step drift tolerance. Everything runs locally; the secret is never uploaded.

  • Enter a Base32 secret or generate a random 160-bit one with crypto.getRandomValues
  • Real RFC 6238 / RFC 4226: HMAC-SHA-1/256/512 via Web Crypto, then dynamic truncation
  • Live current code + countdown ring + next-code preview on your device clock
  • otpauth:// URI and a QR code for Google Authenticator, Authy or password manager apps
  • Verify a code against the secret with ±1 step of clock-skew tolerance

What is

TOTP (Time-Based One-Time Password, RFC 6238)

TOTP is a two-factor-authentication code that changes every few seconds. It extends HOTP (RFC 4226) by using time as the moving factor: the shared Base32 secret and a counter equal to floor(current Unix time / period) are fed into HMAC (SHA-1 by default), and RFC 4226 dynamic truncation reduces the HMAC to a 6- or 8-digit number. Because the server and the authenticator share the same secret and read the same clock, they compute the same code independently — no network round-trip is needed. This tool computes standard TOTP codes entirely in your browser with the native Web Crypto API for setup, testing and backup.

Security & Privacy

Related terms

HOTP (RFC 4226)RFC 6238Base32 (RFC 4648)HMAC-SHA-1otpauth URIGoogle Authenticatortwo-factor authenticationdynamic truncationWeb Crypto APIpasskey / WebAuthn

Frequently Asked Questions

No. The secret and every code are computed entirely in your browser and never leave your device.

The tool is 100% client-side. The HMAC is computed by the browser’s native Web Crypto API (crypto.subtle), random secrets come from crypto.getRandomValues, and the QR is drawn locally — there is no upload, no server, no CDN in the crypto path and no telemetry. Nothing is logged or stored: close the tab and the secret is gone. That said, a TOTP secret is as sensitive as a password — anyone who has it can generate your codes — so only paste real secrets into tools you trust, and prefer a dedicated authenticator app for day-to-day use.

Use SHA-1 with 6 digits and a 30-second period unless your provider explicitly says otherwise.

The overwhelming majority of services — and Google Authenticator itself — use HMAC-SHA-1, 6 digits and a 30-second step, which is why those are the defaults here. RFC 6238 also permits SHA-256 and SHA-512 and 8-digit codes, and a few providers use them, but if you pick an algorithm, digit count or period the server does not expect, the codes simply won’t match. If you import an otpauth:// URI, the correct settings are filled in for you. SHA-1 being “broken” for collisions does not weaken TOTP: HOTP relies on HMAC-SHA-1’s pseudo-randomness, which remains sound.

Almost always a clock problem, or a mismatch in the secret, algorithm, digits or period.

TOTP is derived from the current time, so if your device clock is off by more than about one step (typically 30 seconds) the code will not match — enable automatic network time on your device. The other common causes are a mistyped or wrong-format secret (it must be Base32: letters A–Z and digits 2–7), or an algorithm / digit-count / period that differs from what the service expects. This tool shows the code for the current step, the next step and a ±1-step verify so you can see drift; servers usually accept ±1 step as well.

Use it for setup, testing and backup; for everyday 2FA use a dedicated app on a separate device.

This tool is ideal for setting up a secret, testing that a QR scans, or recovering codes from a secret you have safely stored. For daily logins, though, a dedicated authenticator app on a phone keeps your second factor on a different device from your passwords, which is the whole point of “something you have.” Keeping the secret in the same browser as your password manager collapses two factors into one. And because TOTP can be phished in real time, where a service offers passkeys or hardware security keys (WebAuthn/FIDO2), those are strictly stronger than any TOTP.

Detailed Explanation

How It Works

What the TOTP Generator Does

The TOTP Generator is a 100% client-side tool that produces and verifies time-based one-time passwords — the six-digit 2FA codes used by Google Authenticator, Authy and password manager apps. The user pastes a Base32 secret (or generates a random 160-bit one), picks the HMAC algorithm (SHA-1 by default, or SHA-256 / SHA-512), the digit count (6 or 8) and the period (15 / 30 / 60 seconds). The tool then shows the current RFC 6238 code in large type with a colour-coded countdown ring and a preview of the next code, all refreshed live from the device clock. It also builds the otpauth:// key URI and a scannable QR so the secret can be imported into an authenticator app, and includes a verify box that checks any code against the secret with ±1-step drift tolerance. The secret and every code are computed in the browser and never uploaded.

  • Generates and verifies RFC 6238 TOTP codes entirely in the browser
  • SHA-1 / SHA-256 / SHA-512, 6 or 8 digits, 15 / 30 / 60-second periods
  • Live current + next code with a countdown ring on the device clock
  • Builds the otpauth:// URI and a QR for Google Authenticator / Authy
  • Verify box confirms a code with ±1 step of clock-skew tolerance
Methodology

How the Codes Are Computed

The maths is exactly what an authenticator app runs. First the Base32 secret is decoded to raw bytes per RFC 4648 (alphabet A–Z and 2–7, padding and whitespace tolerated). Then the moving factor is the counter C = floor(currentUnixTime / period), encoded as an 8-byte big-endian integer. The tool computes HMAC(secret, C) using the browser’s native Web Crypto API — crypto.subtle.importKey with { name: "HMAC", hash: "SHA-1" | "SHA-256" | "SHA-512" } followed by crypto.subtle.sign — the same audited implementation used for TLS, never a hand-rolled hash. RFC 4226 dynamic truncation then takes the low nibble of the HMAC’s last byte as an offset, reads the 4 bytes at that offset, masks the top bit to get a 31-bit integer, and reduces it modulo 10^digits, zero-padded. Random secrets are drawn from crypto.getRandomValues (never Math.random), and the whole computation is a pure, fully-typed engine (totpEngine.ts) so it is deterministic and testable.

  • Base32 decode (RFC 4648) → 8-byte big-endian counter = floor(time / period)
  • HMAC-SHA-1/256/512 via native Web Crypto crypto.subtle (not a hand-rolled hash)
  • RFC 4226 dynamic truncation → 31-bit value mod 10^digits, zero-padded
  • Random secrets use crypto.getRandomValues — 160 bits, unpadded Base32
  • Pure totpEngine.ts holds the logic; the page only renders and copies
Technical Details

otpauth URI, QR and Verifying

To enrol a secret in an app, the tool assembles the otpauth://totp/ key URI in Google’s KeyUriFormat: otpauth://totp/Issuer:account?secret=BASE32&issuer=Issuer&algorithm=SHA1&digits=6&period=30, with space-safe percent-encoding (never "+"). That URI is rendered to a QR code locally via the bundled qrcode library — no external QR service — so it can be scanned straight into Google Authenticator, Authy or password manager apps. Pasting an existing otpauth:// URI works in reverse: the parser extracts the secret, issuer, account, algorithm, digit count and period and fills every field automatically. The verify box mirrors how a real server checks a login: it recomputes the code for the current step and ±1 step and reports a match, so a small clock difference between client and server still validates. This is the canonical setup / testing / recovery workflow for a TOTP secret.

  • Builds a Google-Authenticator-compatible otpauth://totp/ URI
  • QR rendered locally with the bundled qrcode library — no QR web service
  • Paste an otpauth:// URI to auto-detect secret, algorithm, digits and period
  • Verify checks the current step and ±1 step, matching typical server tolerance
  • Ideal for enrolling, testing a scan, or recovering codes from a stored secret
Limitations

Honest Limitations

This tool computes standard codes correctly, but it is an aid, not a hardened vault, and a few things matter. The secret is the entire security boundary: anyone who holds it can generate your codes indefinitely, so it must be protected like a password — kept in a password manager or a dedicated app, never pasted into untrusted sites, and cleared when finished. Generating codes in the same browser as your passwords collapses two factors into one, which is why a dedicated authenticator app on a separate device is the right choice for everyday 2FA. Codes are time-derived, so an inaccurate device clock produces wrong codes; the ±1-step verify absorbs only minor drift, and real servers rely on NTP-synced time. Critically, TOTP is phishable in real time — an attacker who relays a valid code within its short window can still authenticate — so where a service supports passkeys or hardware security keys (WebAuthn / FIDO2), those are strictly stronger. SHA-1’s collision weakness does not affect TOTP, which depends on HMAC-SHA-1’s pseudo-randomness, not collision resistance.

  • The secret is everything — treat it exactly like a password
  • For daily 2FA use a dedicated app on a separate device, not this browser
  • Codes depend on an accurate clock; ±1-step tolerance covers only small drift
  • TOTP is phishable in real time — passkeys / security keys are stronger
  • SHA-1 collisions do not weaken TOTP (it relies on HMAC pseudo-randomness)
Privacy & Security

Private by Design

Everything happens on your device. The HMAC is computed by the browser’s native Web Crypto API, random secrets come from crypto.getRandomValues, and the QR code is drawn locally — there is no network request, no upload, no logging, no server and no CDN anywhere in the crypto path. The secret, the live codes and the otpauth URI are just values in memory; nothing is persisted, added to history, or synced, so closing the tab erases everything. The tool works offline once cached, supports dark mode and a mobile-first responsive layout, and has no analytics or telemetry. The only optional network use anywhere on the site is consent-gated ads, which never see your secret or codes. This matters because a TOTP secret is exactly the kind of long-lived credential you would never want to round-trip through a remote service.

  • Secret and codes computed locally via Web Crypto + crypto.getRandomValues
  • No server, no CDN, no upload, no logging, no telemetry, no account
  • Nothing persisted or synced — closing the tab erases the secret
  • Works offline once cached; dark-mode and mobile-first
  • Only optional network use is consent-gated ads that never see the secret
TOTP vs other second factors
Second factorHow it worksPhishing-resistant?Best for
TOTP (authenticator app)Time-based code from a shared secret (RFC 6238)No — real-time relay possibleWidely-supported, offline 2FA
HOTP (counter-based)Code from an incrementing counter (RFC 4226)NoHardware tokens without a clock
SMS / email OTPOne-time code delivered over a network channelNo — also SIM-swap / interceptLast resort where nothing else exists
Passkey / security keyOrigin-bound public-key challenge (WebAuthn/FIDO2)Yes — bound to the real domainThe strongest option when offered

TOTP is a solid, universally-supported second factor and far better than passwords alone, but it is phishable in real time; prefer passkeys or hardware security keys where a service supports them. Everything in this tool runs locally in the browser; the secret is never uploaded. As of July 2026.