OTP Generator
About the OTP Generator
The OTP Generator computes Time-based One-Time Passwords (TOTP) per RFC 6238 entirely in your browser. Add a TOTP secret — manually, via QR-code scan, or by parsing an otpauth:// URI — and the page emits the same six-digit code that Google Authenticator, Authy, 1Password, or any other RFC 6238 client would produce, refreshed every 30 seconds. Unlike a phone-based authenticator, the secret never leaves your device: optional vault encryption uses PBKDF2-derived keys (or WebAuthn PRF on supporting hardware) to wrap each secret with AES-256-GCM in IndexedDB. Use it for developer 2FA testing, ephemeral access without your phone, or any audit and pen-test workflow where you need a code on demand without the round-trip through a phone you may not have on hand.
Updated: May 7, 2026
Related Tools
How to use the OTP generator
- Click Add and either scan a QR code with your camera, upload a QR-code image, paste an otpauth:// URI, or type the Base32 secret manually with optional issuer and account labels.
- Set or unlock the encrypted vault on first use. You can choose a master password (PBKDF2 with 600,000 iterations, the OWASP 2026 recommendation) or a WebAuthn-bound passkey with the PRF extension if your device supports it.
- Each entry shows the current 6-digit code, a countdown bar, and the remaining seconds in the 30-second window. Click the code or the copy icon to drop it into the clipboard.
- Use the export button to write an encrypted backup file (a JSON envelope with an additional KDF layer) to your downloads folder. Move it to whatever offline storage your threat model demands — a printed paper, a USB stick, an encrypted drive.
- Use Lock (or wait for the auto-lock timer to fire) to seal the vault again. Subsequent code generation requires re-authentication.
Common use cases
- Developer 2FA testing. Spin up a test account on a service that requires TOTP, store the secret here, and you can generate codes from the same machine you are running automated tests on — no phone juggling, no round-trip through Google Authenticator while debugging a Selenium flake.
- CI/CD secret rotation drills. When rotating service-account credentials that include TOTP-protected paths, the generator gives a deterministic code stream you can paste into the rotation script — useful for both interactive runs and as a fallback when the production OTP source is being recycled.
- Ephemeral 2FA without a phone. Travel laptop without phone, phone in repair, or phone storage compromised mid-incident: as long as you have a backup of the secret (or the original QR), this tool generates the same codes any other RFC 6238 client would.
- Audit and pen-test workflow. Red team and security audits often need to demonstrate that a given account is reachable without invoking the operator's personal phone. A browser-local, vault-encrypted TOTP generator keeps the test artifact reproducible and out of personal devices.
- Verifying a service's TOTP implementation. Generate codes here against a known-good secret and compare to what your application accepts. Mismatches usually trace to clock drift, the wrong digit count, or a non-default period or algorithm.
Privacy and security
Secrets are stored exclusively in your browser's IndexedDB, encrypted at rest with AES-256-GCM. The data-encryption key is wrapped with AES-KW using a key-encryption key derived from your master password (PBKDF2-HMAC-SHA-256, 600,000 iterations) or your WebAuthn PRF output (HKDF-SHA-256). Plaintext secrets never touch disk, never appear in URL parameters, and are never sent to any server — verifiable by watching the network tab while you generate codes. The page implements idle-based auto-lock and visibility-change auto-lock to limit the time the unwrapped key sits in memory.
Tips and pitfalls
- Clock drift is the #1 cause of "wrong" codes. TOTP is time-based: the algorithm divides the current Unix time by the period (default 30s) and computes HMAC over the resulting counter. If your machine clock is off by more than a half-period, codes will not match. macOS and Windows both expose an NTP-synced clock by default, but virtual machines, dual-boot setups, and devices that have been offline for a while can drift. Verify with date -u and a known-good NTP server.
- Base32 padding bugs trip people up. RFC 4648 Base32 secrets may or may not be padded with = characters, and authenticator apps differ in tolerance. The generator strips padding, normalizes case, and validates the alphabet (A-Z and 2-7), so you can paste secrets in any common variant.
- Always export a vault backup before changing your master password or migrating browsers. Browser storage is not synced across devices by default, and a forgotten master password is unrecoverable — by design.
- TOTP and HOTP are different. HOTP (RFC 4226) is counter-based and used for some hardware tokens; TOTP (RFC 6238) layers time-based counter generation on top of HOTP. Most consumer 2FA is TOTP; if your service uses HOTP, the codes will not match this generator unless you switch the algorithm explicitly.
- Phone-loss recovery: keep the original secret or QR code somewhere offline. Once enrolled, most services do not re-display the secret, so your only recovery paths are (a) the service's account-recovery flow, (b) a stored backup of the secret, or (c) one-time backup codes if the service issues them. Treat the export file from this tool as one such backup.
- Never paste your TOTP secret into a chat, ticketing system, or email — the secret grants permanent code-generation ability until the service rotates it. The same caution applies to QR-code screenshots, which encode the raw secret in their image.
Frequently Asked Questions
- Is this compatible with Google Authenticator and Authy?
- Yes — they all implement RFC 6238 with the same defaults (SHA-1, 6 digits, 30-second period). A secret enrolled in any one of them will produce identical codes in this generator and vice versa. Non-default parameters (SHA-256, SHA-512, 8 digits, 60-second period) are also supported, but check that your service issues a matching otpauth:// URI for them.
- What is TOTP and how does it differ from HOTP?
- TOTP (RFC 6238) is a time-based one-time password: the counter is derived from the current Unix time divided by a configurable period (default 30s). HOTP (RFC 4226) is the counter-based predecessor: each code increments a counter explicitly, used by some hardware tokens like YubiKey OATH-HOTP. TOTP is by far the more common consumer 2FA standard.
- Why does my code not match the service?
- Three usual suspects, in order of frequency: (1) clock drift — your device time is off; verify with an NTP query, (2) algorithm or digit mismatch — the service uses SHA-256 or 8 digits while your entry is the SHA-1/6-digit default, (3) Base32 secret was copied with extra whitespace or a 0/O character substitution. The generator surfaces the parameters of each entry so you can compare them to whatever the service's setup screen documents.
- How is the encrypted vault implemented?
- AES-256-GCM for the secret blob, AES-KW for key wrapping, PBKDF2-HMAC-SHA-256 with 600,000 iterations (OWASP 2026 minimum) for password-derived keys, or HKDF-SHA-256 for WebAuthn PRF outputs. The wrapped key and ciphertext live in IndexedDB; auto-lock fires after 5 minutes of tab hidden or 10 minutes of idle. None of the cryptographic material ever leaves your browser.
- What happens if I lose my master password?
- The vault is unrecoverable — that is the point of password-derived encryption. Reset clears IndexedDB and requires you to re-enroll every secret from your originals or backups. Always export a backup before changing passwords or migrating browsers.
- Can I export my secrets to another authenticator app?
- Yes. The export produces an encrypted JSON envelope. For migration to apps that import otpauth:// URIs, individual entries can also be displayed as their URI form (or QR code), which Google Authenticator, Aegis, Raivo, and 1Password all consume.
- Are hardware tokens supported?
- Indirectly. If your hardware token is OATH-TOTP-compatible (e.g., YubiKey 5 with the OATH applet) you can program the same Base32 secret into both the hardware token and this tool, and they will emit identical codes. Pure FIDO2/WebAuthn keys do not use TOTP — they are an entirely different challenge-response protocol.
- Why a 30-second window?
- 30 seconds is the default period in RFC 6238. Smaller windows force more frequent server-side counter alignment but improve resistance to passive code interception; larger windows are more forgiving of clock drift. Some services pick 60 seconds; the generator honors whatever period is encoded in the otpauth:// URI you import.
- Can I script this for automated tests?
- Not directly — the page is interactive. For programmatic TOTP in a test suite, use the otpauth or pyotp libraries with the same secret you stored here. The standard guarantees that every conforming implementation produces the same codes for the same secret and time.
- What is the otpauth:// URI format?
- otpauth://totp/Issuer:account?secret=BASE32&issuer=Issuer&algorithm=SHA1&digits=6&period=30. The format is documented in the Google Authenticator key URI specification, which has become a de facto standard. QR codes from 2FA-setup pages encode this URI directly; you can paste it into the Add dialog instead of typing the secret.
- How do I back up my secrets safely?
- Use the Export button to download an encrypted JSON file, then move it to whatever offline storage your threat model requires: a printed paper code stored in a safe, an encrypted USB stick, or a hardware password manager. The export file is itself encrypted with a KDF-derived key, so storing it in an everyday cloud drive is risky but not catastrophic — though we recommend offline backup.
- Does the page work offline?
- Yes. After initial load, code generation, vault unlock, and copy-to-clipboard all work without network access. The page makes no outbound requests during normal operation, which you can verify in the browser DevTools network panel.