What Actually Makes a Password Strong (It's Not What You Think)

Most people's mental model of a strong password is "looks random to a human." Swap an "a" for an "@", tack a "!" on the end, capitalize one letter in the middle - it feels like you've made the password harder to guess, because it's harder for you to read at a glance. Attackers, unfortunately, don't guess passwords the way humans read them. They guess with dictionaries, statistics, and raw computing power, and the actual math behind "how long would this take to crack" looks nothing like "does this look messy."

Strength Is Entropy, Not Vibes

The actual measure of a password's resistance to brute-force guessing is its entropy, measured in bits, and it's calculated with one formula: length × log₂(character set size). The character set size is how many distinct symbols could appear in each position - 26 for lowercase-only, 52 for mixed-case letters, 62 with digits added, and so on. Every bit of entropy doubles the number of guesses an attacker would need to try, on average, to find the password by brute force. It's a clean, mechanical number, and it doesn't care whether the password "looks random" to a person reading it - it only cares how large the space of possible passwords actually is and how long the password is within that space.

That formula is also why length dominates the equation so heavily. Adding one more character multiplies the total number of possible passwords by the character set size - for a 62-character set, that's a 62x increase in the search space for a single extra keystroke. Adding an entirely new character class, by contrast, only changes the base of the logarithm slightly. Going from a 62-character set (letters + digits) to an 88-character set (adding common symbols) only adds about log₂(88/62) ≈ 0.5 bits per position - meaningful over a long password, but nowhere near as impactful as just typing four or five more characters of whatever you were already using.

Doing the Actual Math on a Real Example

This site's Password Generator defaults to a 16-character length with all four character classes enabled - lowercase, uppercase, digits, and symbols. Its symbol set is exactly the sixteen characters !@#$%^&*()_+-=[]{}|;:,.<>?, which combined with 26 lowercase, 26 uppercase, and 10 digits gives a total pool of 88 possible characters per position. Plugging that into the formula: log₂(88) ≈ 6.46 bits per character, and 16 × 6.46 ≈ 103 bits of total entropy for the default settings. That's a genuinely enormous search space - roughly 10 nonillion (10³⁰) possible 16-character combinations - well past what any realistic attack, distributed or otherwise, could exhaust within the lifetime of the universe using current or foreseeable hardware.

Now watch what happens as you change one setting at a time. Drop the length to 12 characters with the same 88-character pool and you get 12 × 6.46 ≈ 77 bits - still strong by any practical measure, but the four fewer characters cost you 26 bits, which is the difference between "uncrackable" and merely "very hard." Now instead uncheck the symbols option and keep the length at 16: the pool shrinks to 62 characters (letters + digits), log₂(62) ≈ 5.95 bits per character, for 16 × 5.95 ≈ 95 bits - only an 8-bit drop. Four fewer characters cost more security than removing an entire character class. That's the length-versus-complexity trade-off in one concrete comparison, not an abstract claim.

Why "P@ssw0rd!" Doesn't Fool Anyone

The entropy formula above assumes every character is chosen uniformly at random from the full character set - which is exactly what a proper password generator does, and exactly what a human typing a "clever" password does not do. When a person takes a dictionary word and applies predictable substitutions - "a" to "@", "o" to "0", "s" to "$", a capital letter at the start, an exclamation point at the end - they aren't sampling from an 88-character space at random. They're picking from a tiny, well-documented set of transformations that password-cracking tools have had built into their dictionaries for well over a decade. Modern cracking software doesn't brute-force "P@ssw0rd!" character by character; it takes the word "password" from a dictionary list and mechanically tries the dozen or so common substitution patterns against it, which takes microseconds. The password looks high-entropy to a human eye scanning for symbols and capitals, but its actual guessability is close to that of the plain dictionary word it started from - the formula's assumption of uniform randomness is exactly what breaks when a human, rather than a CSPRNG, is choosing the characters.

Passphrases: Genuinely High Entropy That's Also Memorable

If a random string like the generator's output is hard to remember, a passphrase - several random, unrelated words strung together - is the legitimate alternative, because it gets its entropy from picking words at random from a large list rather than from character-level randomness. If you draw each word uniformly from a list of 7,776 words (a common wordlist size, popularized by the Diceware method, chosen specifically because log₂(7776) works out to almost exactly 12.9 bits per word), four random words give roughly 51.6 bits of entropy, and six random words give about 77 bits - comparable to a solid random password, while being made of words a human can actually memorize and recall. The critical word is random: a phrase you compose yourself, like a memorable sentence or song lyric, draws from the same predictable, attacker-modeled space as "P@ssw0rd!" and doesn't carry anywhere near that entropy. The security comes specifically from the words being selected by a random process, not from the fact that the result happens to be made of dictionary words.

The Generator Itself Is the Easy Part

It's worth being specific about where this site's generator actually earns trust, because the randomness source matters as much as the math above. It draws every character from window.crypto.getRandomValues() - the Web Crypto API's cryptographically secure pseudorandom number generator, backed by the operating system's entropy source - rather than Math.random(), which is specified only for statistical randomness and has been reverse-engineered in some browser engines well enough to predict future outputs from past ones. That's the same category of random source used to generate session tokens and cryptographic keys, not a "good enough for a UI slider" shortcut. There is one minor wrinkle worth knowing: each character is selected with randomValue % charSet.length, which introduces a theoretical, vanishingly small modulo bias when the character set size doesn't evenly divide 2³² - the mathematically pure approach would discard out-of-range values instead of wrapping them. For character sets in the tens of characters against a 32-bit random source, that bias is far smaller than any other real-world risk to the password, but it's the kind of detail worth knowing if you're evaluating the algorithm rather than just trusting the output. The generator's own strength meter, by the way, is a simple threshold heuristic - points for crossing 8/12/16-character length checkpoints plus points per character class present - not a real entropy calculation, so two passwords with meaningfully different actual entropy can both land in its "Very Strong" bucket. Trust the formula above over the bar's label if you need an exact number.

In short: the tool doing the generating was never the weak point. The choices you make with its options - how long, how many character classes, whether you're typing it by hand or pasting from a manager - are what actually determine how strong the result is. You can generate a password with those trade-offs explicit and adjustable using the Password Generator.