Password Entropy: What “Strong” Actually Measures

Password strength is a number of bits, and that number comes from exactly two inputs: how many characters you type, and how many symbols each one could have been. Everything else — the colour bar, the word “secure”, the icon with the padlock — is decoration on top of one formula. This page does the arithmetic, publishes the tables our own generator is built on, and says plainly where the conventional advice went wrong.

The only formula you need

If every character is chosen uniformly at random from a pool of N symbols, each character carries log2(N) bits. Multiply by length and you have the search space:

H = L × log2(N)

Two consequences follow immediately. First, entropy is linear in length: doubling the length doubles the bits, which means doubling the work for an attacker. Second, entropy grows only logarithmically in pool size: adding digits to a lowercase alphabet buys 4.70 → 5.17 bits per character, a 10% gain, while adding eight more characters buys eight times whatever the rate is. Symbols are the expensive, low-yield knob. Length is the cheap, high-yield one.

The grid most generators will not show you

Here is total entropy for the pool sizes people actually pick from. Read across a row and you can see exactly what an extra two characters is worth:

Compare 20 lowercase characters (94.0 bits) with 16 characters drawn from the full alphanumeric-plus-symbols pool (95.3 bits). The all-lowercase string is marginally stronger, is far easier to type, and has no composition-rule problem at all. That single comparison explains why every modern guideline stopped asking for symbols and started asking for length.

Passphrases are the same maths with a bigger log

A passphrase draws words instead of characters. If each word is an independent uniform pick from a list of D words, one word is worth log2(D) bits:

The honest caveat, and it is a big one: that figure only holds for randomly selected words — dice reading off a printed list, or a generator drawing from a real dictionary. When a human “thinks of four words”, the distribution is nowhere near uniform. People pick concrete nouns, prefer short words, favour the first item that comes to mind, and reuse the same handful of images. Measured studies of user-chosen passphrases consistently find effective entropy well below the nominal log2(D). Use a generator for the words and keep only the ordering in your head.

Turning bits into time, and why the rate is the whole story

Expected work to brute force a uniform keyspace is half of it, so the model is time = 2^(H-1) / rate. The rate is the entire argument. The table below is a model, not a measurement — the four rates are illustrative assumptions chosen to span online guessing, a throttled endpoint, one desktop GPU and a large cluster:

Two things this model understates, deliberately worth naming. Real offline attacks do not enumerate the keyspace uniformly; they run rule-based dictionaries and probabilistic grammars learned from leaked corpora, so Passw0rd! has maybe 15 bits of real entropy no matter what the formula says about a 95-character pool. And a target with a leaked database plus GPU hashing of a fast algorithm (unsalted MD5/SHA-1) sits far to the right of that table. Which is the whole reason hashing standards moved to memory-hard functions such as Argon2id and scrypt: the defence is not a longer password, it is making rate expensive.

What the generator on this site actually does

Because it is our own tool, here is the mechanism read from the page source rather than guessed from the interface. It draws 32-bit values with crypto.getRandomValues (a CSPRNG supplied by the browser, not Math.random), clamps length to 8–128 with a default of 20, builds a pool from the character sets you tick, and maps each random value into the pool with a modulo:

out += sets[r[k] % sets.length]

The ambiguous-character option removes lI1O0 from the pool, which is a legibility feature, not a security feature — it costs about two bits at length 20 and you should leave it off for anything you type from memory.

Modulo reduction is technically not uniform: 2^32 is not an exact multiple of the pool size, so some symbols have one extra 32-bit preimage. The worst-case ratio is worth putting in writing because it is the kind of thing people correctly worry about and then over-weight:

A bias of about 1.00000002× is 2×10^-8 — it costs roughly nothing against 128 bits, and is many orders of magnitude below the damage done by choosing your own “random” password. A rejection-sampling implementation removes it entirely; if you want that, the fix is a few lines and we will happily take the pull request through the contact page.

What the standards stopped recommending

NIST’s digital identity guidelines (SP 800-63B, section 5.1.1.2) reversed the conventional wisdom that most people are still repeating. In summary: memorised secrets must be at least 8 characters, must allow at least 64, must allow spaces, and should not be composed of multiple character classes as a requirement; periodic forced rotation without cause is discouraged; and a blocklist against known-breached and dictionary values is required. The reasoning matches the arithmetic above — composition rules cost users bits of real entropy (they write the same pattern every time) while rotation just moves the same weak password around. Treat the summary as a pointer, not a quotation: read the current revision before you cite it in a policy.

Sizing it to the actual threat

• Online service with lockout and no password reuse — 40–50 bits is defensible. The rate limit is doing the work, not your symbols.
• Anything whose hash could be downloaded and cracked offline — 60 bits is not enough on a fast hash. Go 80+ or rely on the server’s memory-hard KDF.
• Full-disk encryption and long-lived backups — 90+ bits, because the attacker can wait and the ciphertext never rate-limits.
• A password manager’s master password — this is the one that carries everything else. Six random words from a 10,000-entry list (79.7 bits) is a sane floor; the manager handles the other 400 accounts.

Frequently asked questions

Related tools

Written and maintained by CHENYUWEN. First published 2026-10-30. If something here is wrong, tell us - corrections are dated on the page.