What Actually Makes a Password Strong

"Use a mix of uppercase, lowercase, numbers, and symbols" is probably the most repeated password advice there is, and it isn't wrong, but it's incomplete enough to be misleading on its own. The actual measure of how hard a password is to guess is called entropy, and once you see how it's calculated, it becomes clear why a long, simple password can beat a short, complex one, not the other way around.

What entropy actually measures

Entropy measures how many possible passwords an attacker would have to try, expressed as a number of bits: entropy = length × log₂(character set size). Each added bit doubles the number of guesses required, so entropy grows fast as length increases, and it grows much more slowly as character set size increases. The Password Generatorcalculates this directly: with all four character types enabled (26 uppercase, 26 lowercase, 10 digits, 26 common symbols, 88 characters total), a 12-character password has about 77.5 bits of entropy, a 16-character password has about 103.4 bits.

Why length beats complexity

Adding a whole new category of character (going from lowercase-only to lowercase-plus-numbers, for example) barely moves the character set size compared to just typing more characters. An 8-character password using all four character types has about 51.7 bits of entropy. A 5-word Diceware-style passphrase, drawn randomly from a standard 7,776-word list, has about 64.6 bits, more entropy than the shorter complex password despite using only lowercase letters and spaces. A 6-word passphrase pushes that to about 77.5 bits, matching a 12-character fully random password while being considerably easier for an actual human being to remember and type correctly. This is the entire basis for the "length beats complexity" advice that's replaced older guidance in most modern security recommendations. A longer password made of ordinary characters usually beats a shorter one stuffed with symbols.

Why this site's generator uses crypto.getRandomValues(), not Math.random()

Entropy calculations assume every possible password is equally likely, which only holds if the characters were actually chosen at random. JavaScript's Math.random() is not cryptographically secure. It's a fast, general-purpose random number generator never designed to resist prediction, and in some browser implementations, its internal state can be reconstructed from a run of outputs. The Password Generator instead uses crypto.getRandomValues(), the Web Crypto API's cryptographically secure random source, so the entropy math above actually holds true, and a generated password isn't secretly more predictable than its length and character set suggest. Nothing about the generation happens on a server either: the whole process runs in your browser, and the result is never transmitted anywhere.

How passwords actually get guessed

The entropy math above assumes an attacker has to try every possible combination, a brute force attack, but that's rarely the first, or most effective, method actually used. Credential stuffing takes usernames and passwords already exposed in a breach at one site and tries them again at other sites, which is why reusing a password anywhere is a real risk even if that exact password was never guessed at all, it only had to be guessed, or leaked, once. Dictionary attacks try real words, common passwords, and known patterns first, since actual human-chosen passwords cluster heavily around a relatively small set of predictable choices, which is exactly why a truly random password (or a passphrase drawn from random words, not a real sentence) resists this approach in a way a memorable, meaningful phrase doesn't. A password's real-world strength depends on all of this, not just its raw entropy against a pure brute-force guess.

Password rules that used to be standard, and no longer are

Mandatory periodic password changes, forcing a new password every 60 or 90 days regardless of whether anything was compromised, used to be close to universal advice. NIST's Special Publication 800-63B, the US government's digital identity guidelines, now explicitly tells verifiers not to require periodic rotation unless there's actual evidence a password has been exposed. The reasoning is straightforward: forced frequent changes push people toward small, predictable variations on their existing password (adding a digit at the end, for example), which measurably weakens security rather than improving it. A password only genuinely needs changing when there's a real reason to believe it's been compromised, not on a fixed calendar.

Letter-for-number substitutions, swapping "a" for "@" or "e" for "3", are another piece of once-common advice that does less than most people assume. These substitutions follow a small, well-known set of patterns, and password-cracking tools have accounted for them for years. A password like "P@ssw0rd" isn't meaningfully harder to guess than "Password", since an attacker's tool tries the substituted version essentially for free while checking the original.

The two ideas that have held up consistently are the ones the entropy math actually supports: make passwords long, and make every password on every account unique, so that one exposed password (from a data breach at a site you have no control over) doesn't put every other account at risk too.