Password Length vs Complexity: The Entropy Math, Worked Out

Every password the password generator produces comes with a number next to it, labelled entropy, measured in bits. Most people ignore it, which is a shame, because that one number settles the oldest argument in password advice: whether you should make passwords longer or make them more complicated. The answer is longer, by a wide margin, and you do not have to take anyone's word for it. The math fits on a napkin.

What the entropy number measures

Entropy here means the number of equally likely passwords the generator could have produced with the settings you chose. It is easier to state in bits than as a raw count, because the counts get absurd quickly. A password with 40 bits of entropy is one of about a trillion possibilities. Every extra bit doubles that.

The formula is short. If the generator picks each character independently from a pool of N possible characters, and the password is L characters long, then:

entropy in bits = L × log2(N)

On this tool the pool depends on which boxes you tick. The four classes are not the full alphabet, because the generator deliberately drops characters that are easy to misread: no capital I or O, no lowercase l, no 0 or 1. That leaves 24 uppercase letters, 25 lowercase letters, 8 digits and 13 symbols (!@#$%^&*-_=+?). With everything on, the pool is 70 characters, so each character contributes log2(70), which is about 6.13 bits. Twenty of them gives 122.6 bits, which the readout rounds to 123.

The table

These are the values the generator will show you, computed from the formula above and rounded the same way the tool rounds. The rating column follows the tool's own thresholds: Weak below 40 bits, Fair from 40, Good from 55, Strong from 75, Excellent from 100.

Read the table across a row and the differences are small. Read it down a column and they are huge. That is the whole argument in one glance.

Length versus complexity, in numbers

Take a 12-character password made of letters and digits: 70 bits. Now do the "complex" thing and switch symbols on. The pool grows from 57 to 70 characters, and entropy rises to 74 bits. You gained about 3.6 bits, and a password that is harder to type on a phone.

Instead, leave symbols off and add a single character. Thirteen letters and digits gives 13 × 5.83, which is about 76 bits. One extra character bought more security than switching on an entire character class, and it will do so at every length, because adding a character multiplies the number of possibilities by the whole pool, while adding a class only nudges the pool size up.

This is also the position of the United States standards body. NIST Special Publication 800-63B tells services to stop forcing composition rules like "must contain a symbol" and to allow long passwords instead, because forced rules push people toward predictable substitutions rather than real randomness.

What the bits mean in guesses

To turn bits into time you need to assume a guessing speed, and that assumption is doing all the work, so it is worth stating. Suppose an attacker who has stolen a database of poorly hashed passwords can test one trillion guesses per second (10¹², a round number in the range that a large rig of graphics cards reaches against a fast hash). Trying every combination then takes:

• 40 bits: about 1 second
• 50 bits: about 19 minutes
• 60 bits: about 13 days
• 70 bits: about 37 years
• 80 bits: about 38,000 years
• 100 bits: about 40 billion years

On average the attacker finds the password halfway through, so halve those. Against a site that hashes passwords properly with a slow algorithm, the guessing rate drops by many orders of magnitude and every line gets far longer. Against a site that stored passwords in plain text, the rate is irrelevant because there is nothing to guess. You do not control which kind of site you are dealing with, which is the practical reason to pick a length that survives the bad case: 16 characters at 98 bits is already past anything worth attacking this way, and the 20-character default gives a comfortable margin.

Why the meter cannot rate a password you made up

The formula assumes every character was chosen uniformly at random. That is true of what the generator outputs and almost never true of what a person types. A password like Summer2026! is 11 characters from a 94-character pool, which would score 72 bits if it were random, but an attacker does not try random strings first. They try dictionary words, years, keyboard runs and the substitutions everyone uses, and that password falls in the first few million guesses. The strength meter on this page is honest about its scope: it measures the randomness of the password it just generated, and nothing else. There is no dictionary check because a uniformly random string has nothing for a dictionary to catch.

What the lookalike rule costs

A generator that used all 94 printable ASCII characters would get about 6.55 bits per character instead of 6.13. At 20 characters that is 131 bits against 123, a difference of 8 bits. In exchange you get passwords that can be read off a screen or over the phone without wondering whether that was a capital I or a lowercase l. Eight bits is a factor of 256 in guesses, which sounds like a lot until you look at the time table above and notice that 123 bits is already in the billions of years. The trade is worth it. If a site insists on a symbol the tool does not include, add it by hand; the fixed symbol set is the one real gap.

Passphrases, for the passwords you have to remember

Random strings belong in a password manager. For the one or two passwords you must hold in your head, such as the manager's own master password, a passphrase made of random words is the same idea in a memorable shape. The EFF's long word list has 7,776 words, so each word chosen at random from it adds log2(7776), about 12.9 bits. Six words gives roughly 77 bits, seven gives 90, and both are far easier to type than a 16-character random string. The word must be chosen by dice or a generator, not by you; the moment you pick words you like, the entropy estimate stops applying for the same reason as above.

How this generator draws its characters

Three details in the code are worth knowing, because they are the difference between a generator that earns its entropy number and one that only claims it.

1. Randomness comes from crypto.getRandomValues, the browser's cryptographic random source, not Math.random, which was never designed to be unpredictable.
2. Each random 32-bit value is mapped onto the pool with rejection sampling. A naive generator takes the value modulo the pool size, and because 2³² does not divide evenly by 70, the first few characters of the pool would come up slightly more often. The tool throws away the small band of values that would cause that skew and draws again.
3. One character from every class you selected is guaranteed to appear, then the whole string is shuffled with a Fisher-Yates pass so the guaranteed characters do not cluster at the front, where a pattern would be easy to spot.

Nothing in that path touches the network. You can load the page, switch on airplane mode, and keep generating.

What to actually do

• Leave the slider at 20 for anything that matters, and never go below 16 for an account you would mind losing.
• Keep all four classes on when the site allows them; if a site rejects symbols, untick them and push the length up four characters, which more than makes up the difference.
• Store the result in a password manager. The password is only as safe as your habit of using a different one everywhere.
• Use a random passphrase for the manager's master password, and treat the entropy number the same way: it only counts if the words were chosen for you.