What an OTP Generator Does
One-Time Passwords (OTP) are the 6-digit codes your authenticator app shows for two-factor authentication. They change every 30 seconds and are derived mathematically from a shared secret you scanned during setup. Google Authenticator, Authy, 1Password, Microsoft Authenticator — all of them implement the same RFC 6238 algorithm. The OTP Generator is a standalone implementation of that algorithm: paste any Base32 secret, get the same 6-digit code your authenticator app would show.
It's useful for testing 2FA flows you're building, debugging login failures (is the issue the code or the verification?), or generating a backup code when your phone is dead. It supports both TOTP (time-based, the common case) and HOTP (counter-based, used by some hardware tokens).
How the Microapp OTP Generator Works
Pick mode (TOTP or HOTP). Paste your Base32 secret — or click "Generate random" for a fresh one you can plug into your authenticator app to test. TOTP refreshes every 30 seconds with a countdown bar; the new code appears automatically when the period rolls. HOTP advances on demand: type the counter or click "+ Next" to bump it.
The HMAC computation runs in your browser using the otplib library. Your secret never leaves your machine — there's no server roundtrip, no logging, no analytics on what you paste. Open the page offline and it still works.
JBSWY3DPEHPK3PXP (a well-known test vector). At a fixed timestamp, the code is exactly the same as what Google Authenticator would show — try it: scan a QR with this secret in any authenticator, then open this tool and paste the secret. The two should display the same 6-digit code at the same moment, every 30 seconds, forever.
TOTP vs HOTP — Which You Have
If you scanned a QR code from a website (Google, GitHub, AWS, your bank, anywhere) into an authenticator app and the code refreshes every 30 seconds, you have TOTP. RFC 6238. Time-based. The counter input is literally the current Unix timestamp divided by 30. Synchronization between client and server requires both to have correct clocks (within ~30s of each other).
If you have a hardware token (YubiKey OTP, RSA SecurID classic, certain banking dongles) where the code changes when you press a button or insert the token, you have HOTP. RFC 4226. Counter-based. Both client and server keep a counter that increments on each successful login. If they fall out of sync (you press the button without logging in, the server resyncs by trying a few counter values ahead).
TOTP dominates because clocks are reliable, no physical token is needed, and resync isn't necessary. HOTP survives in legacy hardware-token deployments.
What's a Base32 Secret
The shared secret between you and the server is encoded as Base32 — uppercase A-Z plus digits 2-7. Why Base32 and not Base64? Because Base32 has no easily-confused characters (no 0/O, no 1/I/L) and is case-insensitive in spec, both of which matter when humans transcribe secrets by hand. Authenticator apps display the secret as a Base32 string under each entry's settings, and accept Base32 input when you type rather than scan.
Length is usually 16-32 characters. Longer secrets are slightly more entropy, but past 16 characters you're not adding meaningful security. The "Generate random" button in this tool produces 16-character secrets — same length Google Authenticator generates for new accounts.
Why Are TOTP Codes Six Digits?
Convention. RFC 6238 supports 6 or 8 digits; almost everyone uses 6. The reason is human-typing: 6 digits is short enough to memorize for the few seconds between reading and typing, while 7 random digits provides enough entropy that brute-forcing within the 30-second window is impractical (a million guesses across 30s = 33,000/sec, way above any login API's rate limit).
Some high-security systems use 8 digits. The math is the same; the user just types two more digits.
Common Pitfalls
Clock skew. If your computer's clock is more than 30 seconds off, your TOTP codes don't match the server's. Most servers tolerate 1-2 periods of drift (60s window) to handle this; beyond that, sync your clock (NTP, or just toggle automatic time on your OS).
Wrong algorithm. Default is HMAC-SHA1, which is what Google Authenticator and 99% of everything else uses. Some servers use HMAC-SHA256 or SHA512 — if your codes never match, check the server's algorithm requirement. They're not interoperable.
Wrong period. Default is 30 seconds. Some systems use 60. If the countdown doesn't match what your phone shows, the period is mismatched.
Lost secret. If you lose your authenticator app and don't have backup codes, you've locked yourself out. Always print or save the secret (or backup codes) when setting up 2FA.
Related Tools
For random secrets to use as TOTP shared secrets, the Token Maker can generate 32-character alphanumeric strings. To build a JWT token (a different kind of authentication token, structured rather than time-based), use the JWT Token Generator. For password hashing on the server-side equivalent of OTP verification, see Bcrypt Generator. To generate the QR codes that authenticator apps scan during setup, the QR Code Generator family is a starting point — though for OTP specifically you'd use the otpauth:// URI format.