What a Password Manager Cannot Measure

The number is about the draw, not about the string

Entropy in bits is log2 of the number of equally likely outcomes. For a password it is length multiplied by log2 of the alphabet size, and the arithmetic is trivial: 12 characters over 62 symbols is 71.5 bits, 15 over 95 is 98.5, 20 over 76 is 125.0. What is not trivial is the condition attached. That formula counts a space of possibilities, and it is only the password's entropy if the password was actually produced by picking uniformly at random inside that space. Entropy is a property of the process that made the string, not of the string you are looking at.

That is the reason a class-counting meter is dangerous rather than merely imprecise. It measures the space you could have drawn from, and reports it as the space you did draw from. An attacker does not walk the alphabet in order — the search is over candidates ranked by prevalence, and a string a person invented sits near the top of that ranking no matter which character classes it happens to satisfy. The tool on this page therefore does something else entirely, and the difference is worth looking at before you trust any number from any meter.

What the tool returns for P@ssw0rd! — and why the page shows two numbers

P@ssw0rd! satisfies every composition rule ever written: nine characters, upper, lower, digit, symbol. Class arithmetic makes that 9 × log2(95) = 59.1 bits, which most meters print as strong. This one returns 6.6 bits and a score of 4 out of 100. It does not split the string at all: it finds P@ssw0rd! whole in its ranked list of common passwords, after folding the leet substitutions @ to a and 0 to o, and charges 96 guesses for the lot. All three crack rows read instant, including the online row that only allows 100 attempts per second. Password1! comes back at 19.8 bits, Motdepasse123! at 26.6, Contrasena1! at 19.8, Passwort!2024 at 16.4. Not one of them is rescued by the symbol on the end.

There is a thing worth knowing about this page, and the tool will not tell you: it carries two different entropy figures. The widget you type into is the guess estimator described above. The worked examples generated below it use length × log2(pool) — the random-draw formula — and are labelled as the length of a randomly generated password for exactly that reason. Both are right about different questions. The widget answers how fast does a human-chosen string fall; the worked examples answer how big is the space a generator draws from. Read them as two instruments, and never carry a number from one over to the other.

The measured ceiling: 300 random passwords, 300 under-reports

The tool ships its own generator, and that generator is solid: it uses rejection sampling on crypto.getRandomValues rather than a modulo, so no character is favoured. Take 300 of its 20-character outputs over the full 95-symbol pool — a true 131.4 bits each — and hand them back to the meter on the same page. The meter under-reported all 300. The mean came back at 124.8 bits, the best draw at 130.7, and the worst at 102.5, which is 28.9 bits short. At 15 characters the mean gap is 5.0 bits; at 24 characters it is 7.3.

This is not a bug, it is the shape of the instrument. A guess estimator searches for the cheapest reading of the string, and in twenty random characters it will always find some three-letter run that happens to be a word, or two adjacent characters that happen to repeat. It charges the cheap reading. So the estimate is a lower bound: it can prove a password is weak, and it can never prove one is strong. The practical rule follows directly. Do not paste a generated password into a meter to decide whether it is long enough — the meter will always mark it down. Decide the length at the generator, from the alphabet and the count, and read the meter only for strings a human invented.

Where the threshold is, and what the standard actually asks for

NIST SP 800-63B-4 became final in July 2025, and it is worth reading because of what it stopped asking for. Verifiers SHALL require a minimum of 15 characters when the password is the only factor, and MAY allow 8 when it sits inside multi-factor authentication. They SHOULD permit at least 64 characters, and SHOULD accept every printing ASCII character, the space, and Unicode. They SHALL NOT impose composition rules — no forced mixture of character types. They SHALL NOT require periodic changes, only a forced change on evidence of compromise. And they SHALL compare a new password against a blocklist of known, commonly used or compromised values.

Read that list again and notice that entropy is not in it. Length is, and a blocklist is. That is the standard telling you where the threshold sits and what replaces the number past it. Fifteen random characters is 89.3 bits over letters and digits, 98.5 bits over the full printable set. Using the crack model the tool itself applies — half the space on average, ten billion guesses a second on a fast hash — 98.5 bits is on the order of 10 to the power of 11 years. Going from 98.5 to 131 bits changes an unreachable number into a larger unreachable number. It buys nothing you can spend.

The three things entropy cannot see

First, reuse. A password with 130 bits of entropy that you also used on a forum which leaked in 2021 is worth zero bits against anyone holding that dump. The attacker does not guess it, they look it up. Entropy has no term for how many other places the string exists, which is precisely why the standard adds a separate blocklist requirement instead of raising the bit count. A single-use password of 15 random characters beats a magnificent one used twice.

Second, what the other end does with it. Entropy prices an offline attack against a stolen hash, and the cost of that attack is set as much by the site's key-derivation choice as by your bits. The same password is worth six orders of magnitude more work against a slow, salted derivation than against a single fast hash, and worth nothing at all against a site that stored it in plain text. You cannot see which of those you are dealing with, you cannot change it, and no meter on any page has any idea either. Third, everything that never involves guessing: a convincing login page, a support agent who resets the account, malware on your own machine, or a stolen session token that skips authentication entirely. A 130-bit password is handed over just as readily as a 30-bit one by someone who believes they are on the real site.

The decision, in order

Generate, do not invent. Any password you compose yourself is a candidate in someone's ranked list, and the meter above will tell you how far down. Fifteen characters from a generator clears the standard's single-factor floor; twenty is the sensible default when nothing has to be typed by hand. Unique per site, without exception, because that is the only variable that turns one breach into one problem rather than all of them. Then a second factor everywhere it is offered, preferring an app or a hardware key to SMS. Then check the accounts that matter against a breach corpus and rotate only what shows up — not on a calendar, which the standard now forbids for exactly the reason you would expect: scheduled rotation makes people pick worse passwords.

The master password of the manager itself is the one place where the number still earns its keep, because it is the one password no blocklist protects and no second factor fully replaces. Make it long, make it random or make it a passphrase of genuinely random words, and never reuse it anywhere. Everything below it can then be twenty meaningless characters you will never see, which is the entire point of the arrangement: you stop optimising a number and start removing the failure modes the number was never measuring.

Frequently asked questions

How many bits should I aim for?

Aim at a length, not a bit count, because length is what you can actually set. Fifteen random characters is the floor NIST SP 800-63B-4 requires of a password used alone, and it is 89.3 bits over letters and digits or 98.5 over the full printable set. Twenty characters, which is what a manager gives you by default, is 125 to 131 bits. Both are past the point where an offline attack is a real threat, so the extra bits are insurance against a future you cannot price rather than a defence against anything today.

The meter gives my generated password fewer bits than the maths says. Which is right?

The maths, if the password really came from a uniform random draw. A guess estimator is a lower bound by construction: it looks for the cheapest way to describe the string and charges that, so any accidental word or repeat inside a random string knocks bits off. Measured here, it under-reported 300 out of 300 twenty-character draws, by an average of 6.6 bits and by as much as 28.9. Use the meter on strings a person invented, and use the generator's alphabet and length on strings a machine made.

Is a password that has never been breached but is reused still safe?

No, and this is the failure entropy is blindest to. A reused password is only as strong as the weakest site that holds it, and you cannot audit those sites. The day any one of them leaks, the string moves from a search space into a lookup table, and its bit count becomes irrelevant. Reuse also converts a single compromise into a cascade across every service sharing the password. The fix is not more bits, it is one password per site, which only stays practical with a manager.

Do symbols and numbers actually help?

They help a generator and they barely help a person. In a random draw, widening the alphabet from 62 to 95 symbols adds about 0.6 bits per character — real, but a single extra character is worth more than the whole widening at that length. Appended by a human they help almost not at all: measured here, Sommer2024! lands at 28.8 bits and Password1! at 19.8, because the estimator prices the word, then the year as a date, then the symbol as one cheap character. This is why NIST SP 800-63B-4 now forbids composition rules outright.

If entropy is so limited, why keep the calculator on the page?

Because it answers one question precisely and that question still comes up: how large is the space a generator draws from, so how long should I set the length. Twelve characters over 62 symbols is 71.5 bits, sixteen is 95.3, twenty over 95 is 131.4 — that is the calculation to make before you press generate. What it cannot do is judge a string you typed, and it cannot see reuse, storage or a second factor. Keep it for sizing a draw; use the analyser above it for anything a person invented; and use neither as the last word on whether an account is safe.