Secure Random Number Generator
How it works
Standard `Math.random()` in JavaScript produces pseudo-random numbers from a deterministic algorithm (typically xorshift128+). While adequate for games and simulations, pseudo-random numbers are cryptographically unsuitable for security-sensitive purposes: secrets, tokens, nonces, and anything an adversary might try to predict. The Secure Random Number Generator uses `crypto.getRandomValues()` — the browser's CSPRNG — backed by OS-level entropy sources (hardware events, timing jitter, device sensors) and independently audited by browser vendors.
**When to use cryptographically secure randomness** - Generating passwords, PINs, or recovery codes - Creating CSRF tokens, nonces, or session identifiers - Producing one-time verification codes (OTPs) - Sampling from a set in a way that must be unpredictable
**Output formats** The generator produces: integers in a specified range (min–max, inclusive); random bytes as hex string; base64-encoded random bytes; UUID v4 (the format 8-4-4-4-12 hex digits, per RFC 4122, with 122 random bits); and random selections from a custom list.
**Entropy and security** 256 bits of randomness from `crypto.getRandomValues()` provides 2²⁵⁶ ≈ 10⁷⁷ possible values — more than the number of atoms in the observable universe. Even a determined attacker with all computing resources on Earth would take longer than the age of the universe to find a specific 256-bit secret by brute force.
**Why not use online random number generators that call an API?** Any API-based random number generator transmits your request to a server — server logs could record that a random token was generated for your IP at a given time. This tool generates randomness entirely client-side: nothing is transmitted.
Privacy: all generation runs locally. No data leaves your browser.
Frequently Asked Questions
- `crypto.getRandomValues()` is the Web Cryptography API's secure random number interface. It draws entropy from the operating system's cryptographically secure random number generator (CSPRNG): on Linux, `/dev/urandom` (backed by kernel entropy pool fed by hardware events); on Windows, `CryptGenRandom`; on macOS, `SecRandomCopyBytes`. These are independently audited by browser vendors and OS security teams, meeting FIPS 140-2 requirements. They are fundamentally different from `Math.random()`, which uses a deterministic algorithm initialised from a system seed.
- For session tokens and CSRF tokens: 128 bits minimum (recommended by OWASP). For password reset tokens: 128 bits minimum. For long-term API keys: 256 bits recommended. For cryptographic keys (AES, ECDH): match the key length (128, 192, or 256 bits). 128 bits = 2¹²⁸ ≈ 3.4 × 10³⁸ possible values — utterly infeasible to brute-force with any known technology. Avoid tokens shorter than 80 bits for any security-sensitive purpose.
- A UUID v4 has 122 random bits (6 bits are fixed for version/variant encoding). 122 bits provides adequate entropy for most session token purposes, and its standardised format makes it easy to store and transmit. However, UUIDs are not constant-time comparable (exposing timing side-channels if compared naively), and their format is predictable (8-4-4-4-12 hex pattern). For high-security applications, a raw 128-bit or 256-bit token encoded as hex or base64 is preferred over UUID v4.
- This tool generates cryptographically secure random bytes suitable as the input material for cryptographic keys. However, generating actual cryptographic keys (RSA, ECDSA, AES) involves more than just randomness — it requires the specific key generation algorithm (prime factorisation for RSA, point multiplication on an elliptic curve for ECDSA). For actual key generation, use the Web Crypto API's `crypto.subtle.generateKey()` method or a trusted cryptographic library. This tool is appropriate for symmetric key material (raw bytes used as AES or HMAC keys).