OTP Code Generator

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.

In your browser it's a live, auto-refreshing preview — paste or generate a secret and it immediately shows the Previous/Current/Next code with a countdown to the next rotation, the secret in hex, the raw counter and its zero-padded hex, and a QR code of the otpauth:// key URI you can scan or open directly. Nothing is uploaded; the whole preview runs client-side.

How to use it

1. Secret (Base32) — paste the shared secret from your authenticator setup (usually the secret= value inside an otpauth:// URI or QR code), or press the refresh button to generate a fresh random one. Lowercase letters and missing = padding are handled automatically.
2. Mode — TOTP ticks the code every period seconds off your device's clock; HOTP advances a counter you increment by hand (a "+1" button is provided) — less common today but still used by some hardware tokens.
3. Advanced settings — hash algorithm (SHA-1 is what almost every app uses; SHA-256/SHA-512 are supported by some) and digit count (6 is standard; a few services use 7 or 8), plus the TOTP period.

The Open Key URI in new tab button opens the same otpauth:// link the QR code encodes — useful for testing a deep link into an authenticator app.

What does the developer API compute, and how does it differ from the live preview?

The API (and any request through /v1 or MCP) is a pure calculator: given a Base32 secret and, for TOTP, an explicit Unix timestamp instead of reading a clock, it returns the exact code for that moment — the same inputs always produce the same output. That's what makes its examples reproducible and lets you check a code against a specific past or future moment (debugging a login failure, verifying a code someone read off a screen minutes ago). The browser preview is the same math, just re-run automatically every tick against Date.now() instead of a timestamp you supply. To reproduce what the preview shows at a given instant via the API, 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 — using the API, the timestamp you passed has to match the real current time within one period; using the live preview, it's your device's own clock that has to be accurate) 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

This tool's QR code and Key URI use a generic "iotools" label — good enough to test that a secret round-trips through a real authenticator app, but not a real provisioning screen. For a otpauth:// URI with your own issuer and account name (what a real 2FA setup QR code encodes), see the TOTP/HOTP Generator.