A password generator cheat sheet distills the math behind a strong random password into a handful of knobs you can read at a glance: length, character pool, and entropy in bits. Strength comes down to one formula — entropy equals length multiplied by log2 of the pool size — so a longer string from a larger character set carries exponentially more randomness than a shorter string loaded with symbols. With uppercase, lowercase, digits, and symbols all enabled, the pool is 86 characters, so each character adds about 6.4 bits; a 16-character password from that full pool lands near 103 bits, well above the rough "strong" threshold against offline brute-force attacks. The cheat-sheet framing matters because most password advice drifts toward folklore: forced rotations, predictable substitutions, mixed-case muscle memory. The real leverage is uniform random selection from a cryptographically secure source, then letting a password manager store the result so you never reuse or recycle a guessable pattern. Below is the reference table of pool sizes, the worked entropy math, the settings that actually change security, and the exact steps to roll a fresh, locally generated password with the Password Generator tool.
Entropy at a Glance — the Numbers Behind Strength
Password strength is not a vibe; it is a measurable quantity called entropy, reported in the same units as information: bits. One bit of entropy halves an attacker's uncertainty, so each additional bit roughly doubles the brute-force workload. The formula behind every password strength meter is straightforward:
entropy (bits) = length × log2(pool size)
Here "length" is the number of characters in the password, and "pool size" is how many distinct characters the generator could have drawn from at each position. If you enable uppercase (26), lowercase (26), digits (10), and a standard set of symbols (24), the pool is 86 characters and log2(86) ≈ 6.426. Plug those numbers in and you can predict the meter reading without booting the tool.
Worked example: a 12-character password with all four pools enabled gives 12 × 6.426 = 77.1 bits of entropy. The same settings at 16 characters give 16 × 6.426 = 102.8 bits, which is where the standard rule-of-thumb shifts from "fair" to "strong". Going to 20 characters pushes the figure to roughly 128.5 bits, well past the level an offline attacker can chew through with commodity hardware. The leap from one extra character is what makes length the dominant lever: every added character multiplies the key space by 86 instead of swapping one symbol for another within a fixed-length string.
The widely cited thresholds are qualitative rules of thumb, not hard cliffs:
- Under ~60 bits: weak; tractable for offline cracking rigs and leaked-hash dumps.
- 60 to 100 bits: fair; resistant against many online attacks but vulnerable to dedicated offline brute force.
- 100+ bits: strong; far beyond the reach of conventional offline brute force against a properly hashed secret.
The Pools You Actually Toggle
The "character types" checkboxes in any password tool map to four pools. Their sizes are exact, and the totals determine every entropy number above.
| Toggle | Pool size | Example characters |
|---|---|---|
| Uppercase (A–Z) | 26 | A, B, C … Z |
| Lowercase (a–z) | 26 | a, b, c … z |
| Digits (0–9) | 10 | 0, 1, 2 … 9 |
| Symbols | 24 | ! @ # $ % ^ & * ( ) _ + - = [ ] { } | ; : , . ? |
| All four combined | 86 | — |
| Letters only (upper + lower) | 52 | a–z, A–Z |
| Alphanumeric (no symbols) | 62 | a–z, A–Z, 0–9 |
Notice that adding the symbols pool only adds 24 characters to the key space, while enabling lowercase on top of uppercase adds 26. That asymmetry is why the marginal entropy gain from "throwing in a $ symbol" is so small compared to adding a single character of length. It is also why the symbol pool alone is the worst bargain if you have to choose between length and complexity: a 16-character password over 86 characters beats a 12-character one over the same 86 every time, by a factor of more than 1,000 in key space.
Settings That Change Real Security
The control panel of the Password Generator exposes four inputs, and only two of them dominate the security outcome. The rest are quality-of-life tweaks.
1. Length (the dominant lever). Length controls the exponent in the entropy formula. Set the slider or number box to at least 16 for accounts that matter, and treat 20 or more as the default for master passwords, encryption passphrases, and any secret that guards other secrets. The "100+ bits" target is reachable in 16 characters when all four pools are on; raise the length and you can keep the bits even if you trim a pool.
2. Character pool selection. The more pools you enable, the larger the per-character contribution to entropy. Leave all four on for general use. The narrow case for disabling a pool is when the destination system cannot accept that character class — some legacy hardware rejects symbols, some PIN fields reject letters — and even then, raising length by 2 usually recovers the lost bits.
3. Exclude ambiguous characters (0, O, 1, l). Excluding the four characters most easily confused when reading a password aloud trades a small amount of entropy for human-friendliness. With all four pools on, dropping those four shrinks the pool from 86 to 82, costing about 0.07 bits per character — invisible at length 16. Enable the toggle only when you must read or type the password by hand; leave it off otherwise.
4. Strength and entropy readout. Treat the bits number as the actual score. A reading under 60 bits calls for more length or more pools. A reading between 60 and 100 bits is acceptable for low-value accounts. A reading of 100 or more bits is the practical target for anything that touches money, identity, or other credentials.
The cheat-sheet summary in rule form:
- Length first, complexity second.
- Keep all four pools on unless a target system forbids one.
- Aim for 100 or more bits of entropy for accounts that matter.
- Leave "exclude ambiguous" off by default.
- Roll a fresh password per site — never reuse or rotate predictably.
How to Generate a Strong Password in Your Browser
Once you know the targets, the actual generation takes three clicks. Everything runs locally — there is no server, no upload, and no log.
- Set the length. Drag the slider or type into the number box. Start at 16 characters; raise to 20 or 24 for master passwords and encryption keys.
- Toggle the character pools. Leave uppercase, lowercase, digits, and symbols all enabled for the largest pool (86 characters). Optionally enable the "exclude ambiguous characters" filter if you will be reading or typing the result.
- Read the strength and entropy estimate, then copy or roll a fresh one. Confirm the bits readout lands at 100 or higher. Click Copy to send the password to your clipboard, or click Generate new password to roll another candidate if you want a different one. Paste the result straight into your password manager's "new password" field; close the browser tab to discard the in-memory copy.
If your password manager has its own built-in "generate password" feature, point it at the same defaults — 16 or more characters, all four pools, at least 100 bits — and use the local tool as a fallback or audit reference when you want to verify what any generator is actually producing.
Why CSPRNG Beats Math.random and Human Guesswork
A high-entropy string from a small character set is no better than a low-entropy string from a large one if the underlying randomness is predictable. Two implementation details separate a real generator from a counterfeit one.
crypto.getRandomValues, not Math.random. JavaScript's built-in Math.random() is fast but not cryptographically secure; its internal state can be reconstructed from a short sequence of outputs, which means a password built on it carries far less true randomness than its length suggests. The browser-exposed Crypto.getRandomValues() API is a CSPRNG — a source designed to be unpredictable even to an attacker who knows every previous output — and is what the Password Generator uses under the hood.
Rejection sampling instead of modulo bias. Mapping a raw random number onto a character pool with a plain % poolSize introduces modulo bias when the pool size does not evenly divide the random number's range, so some characters get picked slightly more often than others. That shrinks true entropy and makes output marginally more predictable. The generator discards any random value that would fall into the biased remainder and draws a fresh one, so every character in the selected pool is chosen with exactly equal probability.
Guaranteed coverage plus Fisher–Yates shuffle. Once the random characters are drawn, the generator guarantees at least one character from each selected pool — so you cannot roll "all lowercase" by chance even though every position was independently random. It then shuffles the entire string with the Fisher–Yates algorithm so the guaranteed characters are never pinned to fixed positions, removing the predictable pattern an attacker could otherwise exploit.
What NIST SP 800-63B and OWASP Actually Recommend
The two documents most often cited in password policy work have converged on the same handful of points, and both push back against the complexity folklore.
NIST SP 800-63B. The Digital Identity Guidelines explicitly favor long passwords or passphrases over forced complexity rules, and push back against mandatory periodic rotation unless a compromise is known. The guideline also recommends screening candidate passwords against known breached-password lists before accepting them, so the system can reject "Password123!" even if it meets length and symbol requirements.
OWASP Authentication Cheat Sheet. The OWASP Authentication Cheat Sheet echoes the same priorities: length over complexity, unique passwords per service, credential storage using memory-hard or adaptive hashes (Argon2, scrypt, bcrypt), and rate-limiting or CAPTCHA on the authentication endpoint to push back against online brute force.
The operational takeaway lines up with the cheat sheet's math: a long, random, unique password generated by a CSPRNG-backed tool and stored in a password manager beats a shorter, hand-rolled, reused "complex" string on every axis that matters — entropy, breach exposure, and resistance to offline cracking. Excluding ambiguous characters and trimming the symbol pool are ergonomics for readability, not security measures.
Quick Reference Card
The one-screen summary, for the next time you need the numbers without scrolling through the rest of the cheat sheet.
| Length (all pools on, pool = 86) | Entropy (bits) | Strength band |
|---|---|---|
| 8 | ~51 | Weak |
| 12 | ~77 | Fair |
| 16 | ~103 | Strong |
| 20 | ~129 | Strong |
| 24 | ~154 | Strong |
Cheat-sheet rules in one line each:
- Length first; complexity second.
- All four pools on gives the largest key space per character.
- 16 or more characters, or 100 or more bits, for accounts that matter.
- Exclude ambiguous characters only when reading or typing by hand.
- One password per site, stored in a password manager.
- Generation is local; nothing is uploaded or stored server-side.
If you're weighing options, Looking for a Password Strength Checker Alternative? covers this in detail.