Password Generator

What is a password generator?#

A password generator turns a source of real randomness into a string of characters you can use as a credential. The point is not just “make it long” — it is to draw from a character pool uniformly, so every possible password of your chosen length is equally likely. That uniformity is what lets you reason about strength mathematically: a 16-character password over 93 characters carries about 105 bits of entropy, full stop, with no human bias to exploit.

This page uses crypto.getRandomValues, the browser’s cryptographically strong random source, and it does the draw with rejection sampling. That detail matters: the naive shortcut of taking randomByte % poolSize introduces modulo bias when the pool size does not divide 256 evenly. Rejection sampling throws back the biased leftovers, so the selection is unbiased for any pool — including the awkward 93-character full set.

The strength readout underneath the result is computed honestly as length × log2(poolSize) — Shannon entropy — and bucketed into weak / fair / good / strong. It reflects the pool you actually selected, not a guess.

How to use it#

1. Set the length. The default of 16 is a good all-purpose length; the field accepts up to 4096.
2. Tick the character classes to include: lowercase, uppercase, digits, symbols. Lowercase, uppercase, and digits are on by default; symbols are off because some login forms reject them.
3. Optionally tick Exclude similar to drop visually confusable characters (i l 1 L o 0 O and a few quote-like symbols) — useful when the password will be read aloud or typed by hand.
4. Click Generate, then Copy. The status line reports the entropy in bits and a strength label derived from the pool and length you chose.

Key features#

• Unbiased randomness. Rejection sampling over crypto.getRandomValues means no modulo bias, even on pools whose size is not a power of two.
• Honest strength meter. Entropy is computed from the actual pool size and length, not estimated by eyeballing the characters; the weak / fair / good / strong buckets map to fixed bit thresholds (28 / 60 / 100).
• Exclude-similar mode. Strips the characters most likely to be misread, for passwords humans must transcribe.
• Tunable up to 4096. Whether you want a 16-character login password or a 64-character API key, the same generator handles it.
• Zero upload. Generation is entirely local; the password is never sent over a network.

Worked example#

With length 16, all four classes enabled (lowercase + uppercase + digits + symbols) and Exclude similar off, the pool is 93 characters (26 + 26 + 10 + 31). The entropy is therefore 16 × log2(93) ≈ 16 × 6.54 ≈ 105 bits, which lands in the strong band (≥ 100 bits). A generated result looks like:

qM8#fT2$vRkL9@hZ

Turn on Exclude similar and the pool drops to 85 (eight confusable characters removed), giving 16 × log2(85) ≈ 103 bits — still strong, but now safe to read over the phone.

For contrast: drop to length 12 with only lowercase + digits (pool of 36), and the entropy falls to 12 × log2(36) ≈ 62 bits — only good. That drop, from 105 to 62 bits, is not a rounding error: it is roughly 2^43 times faster to brute-force, which is exactly why character pool and length both matter.

FAQ#

How long is “long enough”?#

For a login password behind a rate-limited service, 12–16 characters from a broad pool is comfortable. For an API key or a password you store in a manager with no online rate limit protecting it, aim for 25+ characters. The strength meter tells you the truth in bits — anything at or above 100 bits is considered strong against offline brute force on today’s hardware.

Why does the same setting produce a different password each time?#

Because the underlying random bytes are fresh on every click. That is the whole point — if the output were predictable, an attacker could predict it too. There is no seed you can fix, by design.

Should I include symbols?#

Include them unless the destination system rejects them. Symbols widen the pool (from 62 to 93 characters for the default set), which directly raises entropy per character. The common reason to leave them off is a login form that bans certain punctuation, not a security trade-off.

Is a generated password safer than one I invent?#

Almost always yes. Humans are terrible at randomness — we cluster on common words, repeated patterns, and keyboard walks that dictionaries are built around. A generator drawing uniformly from a defined pool has no such habits, so a 16-character generated password is reliably stronger than a 12-character human-chosen one that feels clever.