A strong password is long and drawn from a large, unpredictable character pool. The biggest single mistake password tools make is using Math.random, which is fast but predictable — completely unsuitable for secrets. This generator uses the Web Crypto API, builds each password from cryptographically secure random bytes, and lets you match any site’s policy: set the length and choose which character sets to include, with an option to drop look-alike characters so the password is easy to type. Everything runs in your browser.
How it works
The generator assembles a character pool from the sets you enable, then samples from it without bias:
- Build the pool from the enabled sets — uppercase, lowercase, numbers, symbols — optionally removing ambiguous characters like
0,O,1,l, andI. - For each position, pick a character using
crypto.getRandomValueswith rejection sampling, which discards values that would skew the distribution so every character is equally likely. - To satisfy a policy requiring certain character types, place one character from each required set first, fill the remaining positions from the full pool, then shuffle the whole string with a Fisher-Yates shuffle so the guaranteed characters are not predictably positioned.
Rejection sampling matters: naively taking a random byte modulo the pool size makes lower-indexed characters slightly more common, which subtly weakens the password. This tool avoids that.
Why Math.random is not safe for passwords
JavaScript’s Math.random is a pseudorandom number generator seeded from a small internal state. It produces numbers that pass statistical randomness tests but are fundamentally deterministic — if an attacker knows the seed or the algorithm, they can predict the sequence. Browser implementations vary, but none are designed for cryptographic security.
crypto.getRandomValues draws from the operating system’s entropy pool (hardware events, timing noise, and other unpredictable sources) and is designed specifically for generating secrets. There is no sequence to predict — each call is independent of the last.
Password length and entropy
The strength of a random password is measured in bits of entropy: the base-2 logarithm of the number of possible passwords of that length from that character pool.
| Length | Pool (all 4 sets, ~94 chars) | Entropy |
|---|---|---|
| 8 | 94^8 | ~52 bits |
| 12 | 94^12 | ~79 bits |
| 16 | 94^16 | ~105 bits |
| 20 | 94^20 | ~131 bits |
52 bits was considered acceptable years ago but is now marginal against GPU-accelerated cracking in offline attacks on compromised hashes. 80 bits is a reasonable floor for important accounts; 100 bits or more gives a large margin. Length is the most efficient way to add entropy — each extra character at the 94-char pool adds about 6.5 bits.
Choosing a policy
- Length beats complexity. A 16-character lowercase password is far harder to crack than an 8-character password with every symbol. Prefer longer.
- Use a password manager. Length stops being a typing problem when you never type your passwords by hand. Generate at 20+ characters and let the manager fill them in.
- Excluding ambiguous characters trims the pool from ~94 to ~87 characters — a small reduction (about 0.1 bits per character). If you must type the password manually, the trade-off is worth it; otherwise leave them in.
- Symbols matter for policy compliance, not entropy.** Many sites require at least one symbol. The generator guarantees policy compliance when you enable a set, by placing one character from each required set before filling the rest randomly.
No password generated here is transmitted or stored anywhere — it exists only in your browser until you copy it.