OTP Generator

What is an OTP?

OTP — One-Time Password — is a numeric (or alphanumeric) code that is valid for a single authentication attempt, then discarded. The pattern predates the web: hardware tokens like RSA SecurID popularised it in the 1990s, and today every bank SMS code, every password-reset email and every “we sent a code to your phone” flow is an OTP. The defining property is freshness: the code only works once, and only for a short window.

A plain OTP — as opposed to TOTP or HOTP — is just a random number that the server generates, stores with a TTL, sends to the user out of band, and compares against the user’s submission. There is no shared secret, no rolling clock, no HMAC. The cryptography is in how the number is generated (a CSPRNG, never Math.random) and how it is stored (hashed at rest is overkill but never plain-text in logs).

How it works

The algorithm is intentionally trivial:

1. Pull n cryptographically random bytes from the OS RNG. In a browser this is crypto.getRandomValues(new Uint8Array(n)); on a Node server it is crypto.randomBytes(n).
2. Convert those bytes to a decimal number in the range [0, 10ⁿ) — typically by taking the value modulo 10ⁿ while being careful to reject the small biased range at the top of 2⁸ⁿ for very short codes.
3. Left-pad with zeros to the desired digit count so 42 becomes 000042 and the code is always exactly n digits wide.

Step 1 is the entire security story. crypto.getRandomValues is backed by the operating system’s CSPRNG — /dev/urandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS — and is the only acceptable source for a one-time secret.

Common use cases

• SMS or email verification codes. Sign-up confirmation, login challenges, “is this you?” prompts. The OTP is generated server-side, stored against the session or user row with a 5–15 minute TTL, delivered over SMS / email, and validated on submission.
• Password reset flows. Instead of a long opaque URL token, some systems send a 6- or 8-digit code that the user pastes into the reset form. Easier on mobile and less likely to be truncated by mail clients.
• Phone-number ownership checks. Confirming a new phone number for 2FA enrolment, account recovery, or for a marketplace seller verification.
• Step-up authentication. Re-confirming identity before a sensitive action (changing email, transferring funds) without requiring a full re-login.
• Test data and local development. Seeding fixtures with realistic six-digit codes that you can paste into a UI under test.

How to use this OTP generator

1. Choose a digit count — 4, 6 or 8. Six is the most common default; eight is a good pick for high-stakes single-factor codes like account recovery.
2. Optionally set a bulk count if you need several codes at once (for example, generating a sheet of one-time scratch codes).
3. Click Generate. The codes are produced from crypto.getRandomValues, zero-padded to the requested width, and displayed for copy-and-paste.
4. Click any code to copy it to the clipboard, or use Copy all to grab the full list.

Security considerations

A plain OTP is only as strong as the surrounding flow. Two parameters matter more than the code itself:

• Time-to-live. Shorter is safer. 5–10 minutes is a reasonable default for SMS and email; longer TTLs widen the brute-force window unnecessarily. Once the TTL expires, the stored code must be invalidated server-side, not merely hidden from the UI.
• Attempt limits. With a 6-digit code there are one million possibilities — an attacker hitting your endpoint at 10 requests per second cracks that in 28 hours unless you lock the attempt after, say, 5 wrong tries. Per-account, per-IP and global rate limits should all be in place.
• Single-use enforcement. The moment a code is submitted — correct or not — it should be consumed so that a leaked SMS cannot be replayed. Don’t merely flag it; delete it.
• Don’t log codes. OTPs in application logs, error reports or analytics pipelines have caused real breaches. Treat them as secrets, not events.
• Use a CSPRNG, never Math.random. This sounds obvious; the number of production OTP flows that have shipped with Math.random() is non-trivial.

Privacy

Every code is generated by your browser’s Web Crypto CSPRNG on this tab. There is no upload, no server-side state, no analytics. After loading the page the only network requests you will see are the cached JavaScript bundle and font files — and even those work offline. Nothing about the codes you produce ever leaves your machine.

Compatibility notes

The generator needs only crypto.getRandomValues, which has shipped in every browser since IE 11. The output is plain digit strings: any backend that compares strings or parses integers will accept them. The codes are not formatted into any specific provisioning URL or QR code — for that, you want the TOTP generator instead.