OTP Code Generator
Generate TOTP (time-based, RFC 6238) and HOTP (counter-based, RFC 4226) one-time passcodes from a Base32 secret — the same 2FA codes an authenticator app produces, computed entirely in your browser.
Input
The Base32-encoded shared secret from your authenticator setup (the otpauth:// secret= value). Lowercase and missing padding are handled automatically.
The moment to compute the code for. This tool never reads your clock, so the same timestamp always reproduces the same code — paste the current Unix time for a code that matches your authenticator app right now.
How often the code rotates. 30 seconds is the near-universal default.
Output
For TOTP this is floor(timestamp / period); for HOTP it is the counter you entered.
Guides
The OTP Code Generator computes the six-to-eight digit one-time passcode that an authenticator app (Google Authenticator, Authy, 1Password, Microsoft Authenticator, …) would show for a given Base32 secret — using the same math those apps run internally. It supports both TOTP (time-based, RFC 6238) and HOTP (counter-based, RFC 4226), the two standards nearly every two-factor authentication (2FA) system is built on.
Everything runs in your browser. Your secret is never uploaded — treat this as a scratchpad for debugging or testing a 2FA integration, not a place to park a production credential long-term.
How to use it
- Mode — choose TOTP for the familiar 30-second rotating code, or HOTP for systems that advance a counter instead of a clock (HOTP is less common today but still used by some hardware tokens).
- Secret (Base32) — paste the shared secret from your authenticator setup, usually the
secret=value inside anotpauth://URI or QR code. Lowercase letters and missing=padding are handled automatically. - Hash algorithm — SHA-1 is what almost every authenticator app uses; SHA-256 and SHA-512 are supported by some (Steam Guard-style and hardware tokens sometimes use them).
- Digits — 6 is standard; a few services use 7 or 8.
- For TOTP: enter a Unix timestamp (seconds since 1970-01-01) and a period (usually 30 seconds). For HOTP: enter the counter value directly.
The output shows the generated code, the counter value actually used (for TOTP this is floor(timestamp / period)), and — for TOTP — how many seconds remain in that time window.
Why does it ask for a timestamp instead of just showing the current code?
A real authenticator app reads your device's clock every second. This tool is a pure calculator: the same inputs always produce the same output, which is what makes its examples reproducible and lets you check a code against a specific past or future moment (useful when debugging a login failure or verifying a code someone read off a screen minutes ago). To match what your authenticator shows right now, paste the current Unix time — in a browser console, Math.floor(Date.now() / 1000) gives you that number.
Frequently asked questions
What's the difference between TOTP and HOTP?
Both derive a code from a shared secret and a counter using HMAC. TOTP computes the counter from the current time (floor(unixTime / period)), so the code rotates automatically — no state to track. HOTP uses an explicit counter that increments by one every time a code is generated or used, so the server and the token must stay in sync some other way. TOTP is the far more common choice for web 2FA today.
Where do I get the Base32 secret?
Whichever service is setting up 2FA gives you either a QR code or a "can't scan? enter this key" text string — that text string is the Base32 secret. Scanning the QR code encodes an otpauth://totp/Issuer:user?secret=XXXX&... URI; the secret= parameter is exactly what belongs in this tool.
Why did I get a different code than my authenticator app?
The two most common causes: a clock mismatch (TOTP is time-sensitive — if the timestamp you entered doesn't match the real current time within one period, the codes won't match) and a wrong algorithm/digit count (a handful of services use SHA-256/SHA-512 or 7-8 digits instead of the SHA-1/6-digit default). Double-check both against the issuer's setup instructions.
Is this safe to use with a real account's 2FA secret?
The computation happens entirely in your browser — the secret is never sent anywhere, and the tool's shareable-link feature deliberately excludes it. That said, a 2FA secret is a long-lived credential: pasting it into any web page carries some risk if the device itself is compromised. It's best suited to testing with secrets you control, or to secrets you're actively rotating out.
How was this verified against the standard?
Against the published RFC 6238 Appendix B and RFC 4226 Appendix D test vectors — the canonical, publicly documented reference values for TOTP and HOTP. The tool's built-in examples reproduce those exact codes.
I'm setting up a brand-new 2FA secret, not verifying an existing one
See the TOTP/HOTP Generator, which builds the otpauth:// provisioning URI (issuer + account + secret) that a 2FA setup QR code encodes.