Password Entropy Explained: What 'Bits of Entropy' Really Mean

“Use a strong password” is advice everyone has heard and almost nobody can quantify. Is P@ssw0rd1 strong? It has an uppercase letter, a symbol and a digit — every box ticked — yet it would fall to an offline cracker in well under a second. Meanwhile correct horse battery staple, four ordinary lowercase words with spaces, would take longer than the age of the universe. The reason those intuitions are backwards is entropy: the single number that actually measures how hard a password is to guess. This guide explains what entropy is, how it’s calculated, and why the result so often contradicts the “complexity rules” we were all taught.

What entropy actually measures

Entropy, measured in bits, is the size of the haystack an attacker has to search. Each bit doubles the number of possible passwords. A password with 40 bits of entropy could be any one of 2⁴⁰ ≈ 1.1 trillion combinations; add ten more bits and you’re at 2⁵⁰ ≈ 1.1 quadrillion — a thousand times harder. Because the relationship is exponential, small-looking changes in the bit count are enormous changes in real difficulty.

Crucially, entropy measures the generation process, not the characters on screen. A password is only as unguessable as the procedure that produced it. This is why entropy estimates are always a best-case figure: they assume every character was chosen at random from its pool. If you picked a real word, the true entropy is far lower, because an attacker doesn’t guess letter by letter — they guess word by word from a dictionary.

The formula: length × log₂(pool size)

The calculation behind the Password Strength & Entropy Calculator is exactly this:

entropy (bits) = length × log₂(pool size)

Pool size is how many distinct characters could appear in each position, inferred from the classes your password actually uses. The calculator adds:

• +26 for lowercase letters (a–z)
• +26 for uppercase letters (A–Z)
• +10 for digits (0–9)
• +33 for symbols (!@#$%…)
• +1 for spaces
• +100 for any non-ASCII Unicode

So a 12-character password using lowercase, uppercase and digits draws from a pool of 26 + 26 + 10 = 62 characters. That’s 12 × log₂(62) ≈ 12 × 5.95 ≈ 71.4 bits. Add symbols and the pool jumps to 95, lifting each character to log₂(95) ≈ 6.57 bits.

Notice what dominates the equation. Pool size sits inside a logarithm, so doubling it adds only one bit per character. Length sits outside as a plain multiplier. Every extra character adds its full per-character bit value; widening the pool barely moves the needle. Going from 8 to 16 characters does far more for you than sprinkling in a symbol. That single insight is why modern guidance favours long passphrases over short, “complex” strings.

Why the crack-time table changes by attacker

A bit count is abstract, so the calculator translates it into time-to-crack — but that depends entirely on who is guessing and how fast. The same password is shown against six attacker tiers, from a throttled login form trying ~100 guesses per second up to a nation-state ASIC array at 10¹⁴ guesses per second. The estimated time is:

time = (2^bits / 2) ÷ guesses-per-second

The ÷ 2 is there because, on average, an attacker finds your password halfway through the search space — they don’t have to exhaust all of it. The gap between tiers is staggering: a password that survives “billions of years” against an online login form might fall in hours against an offline GPU farm with your leaked password hash in hand. That’s the whole argument for slow password hashing (bcrypt, scrypt, Argon2) on the server side — it drags every attacker tier back down toward the throttled end of the table.

The rating bands

The calculator labels the result so you don’t have to memorise thresholds:

• Under 28 bits — Very weak. Crackable essentially instantly.
• 28–35 bits — Weak. Falls to offline attacks in seconds to minutes.
• 36–59 bits — Fair. The deceptive middle: fine against throttled online attacks, weak offline.
• 60–79 bits — Strong. A sensible target for important accounts.
• 80–127 bits — Excellent. Comfortably beyond reach of any current hardware.
• 128+ bits — Overkill. The realm of cryptographic keys.

Aim for the Strong band or better on anything that matters. Sixty bits is roughly a 10-character fully random password from the 95-character pool, or a four-word random passphrase.

Why the math lies about real passwords — and the fix

Here is the catch that the entropy number cannot see: it assumes randomness it can’t verify. Password123! scores in the “Fair” range on raw entropy, but it is one of the first strings any real cracking tool tries, because attackers run dictionaries, leaked-password lists, and substitution rules (a→@, o→0, s→$) before they ever resort to brute force. The formula counts the theoretical search space; a smart attacker shrinks the practical one to almost nothing by guessing how humans actually behave.

That is exactly why correct horse battery staple wins. Four common words look simple, but if each is chosen randomly from a list of, say, 7,776 words, the passphrase carries about 4 × log₂(7776) ≈ 51 bits from the word choice alone — and the calculator, seeing 28 lowercase characters plus spaces, rates it strongly too. The strength comes from genuine randomness in the selection, not from visual messiness.

So treat the calculator as a measure of your method, not a stamp of approval on a clever-looking string:

• Length beats complexity. Reach for 16+ characters, or four-plus random words.
• Randomness must be real. Let a password manager generate it, or pick passphrase words with dice or a tool — never “think one up.”
• Never reuse. Entropy protects one account; reuse hands an attacker every account at once.
• Add a second factor. Even a strong password is one breach away from exposure; 2FA covers the gap.

Try it on your own passwords

Type a candidate into the Password Strength & Entropy Calculator — it runs entirely in your browser, so nothing is ever sent anywhere — and watch the bit count, the character-pool breakdown and the per-attacker crack times update as you type. Try lengthening a password versus adding symbols and you’ll see the length multiplier win every time. If you build or debug tooling, you may also find the Regex Tester & Explainer handy for validating password-policy patterns, and the Unix Timestamp Converter useful when reading credential-expiry fields in logs and tokens.

General security information, not a guarantee. Entropy estimates assume randomly generated input; reused, dictionary-based or predictable passwords are far weaker than their bit count suggests.