Password entropy is a way of counting how many equally likely passwords could have come out of the method you used to make yours. Password entropy is measured in bits, and a password with n bits of entropy is one of 2ⁿ equally likely possibilities, so each extra bit doubles the number of guesses an attacker might need. A 60-bit password belongs to a pool of about 1.15 quintillion candidates. An attacker searching at random will, on average, find it about halfway through.
That single idea explains most of what you see on strength meters and password generators. It also clarifies why “P@ssw0rd!” scores poorly despite its symbols, while four random dictionary words can hold up well.
Once you can read bits of entropy, you can judge a generator setting, compare a passphrase with a random string, and pick sensible targets for your own accounts. You can do all of that without a cryptography background.
Why Each Extra Bit Doubles the Possibilities
A bit is one yes-or-no choice, so every bit you add doubles the count of possibilities. One bit gives you 2 options. Two bits give you 4. Ten bits give you 1,024. Entropy in bits is the base-2 logarithm of the number of equally likely outcomes: it tells you how many coin flips would produce the same amount of uncertainty.
The idea comes from information theory. Claude Shannon introduced it in his 1948 paper “A Mathematical Theory of Communication” to measure uncertainty in messages. Applied to passwords, the full set of possibilities is called the keyspace. Each extra bit doubles the keyspace, which means it doubles the work of an exhaustive search.
Two numbers describe that search, and many explanations blur them:
- Total keyspace: a uniformly random n-bit secret has 2ⁿ possibilities. An attacker who tries every one is guaranteed to succeed after 2ⁿ guesses.
- Average guesses: on average, the attacker finds it after about 2ⁿ⁻¹ guesses, half the keyspace.
That halving is worth exactly one bit, and the difference is small. The important point is the direction. Ten extra bits multiply the work by 1,024, and twenty extra bits multiply it by about a million.
What Do 40, 60, and 80 Bits Actually Represent?
Here is what the common milestones mean in plain counts:
| Entropy | Possibilities (2ⁿ) | Average guesses (2ⁿ⁻¹) |
|---|---|---|
| 40 bits | about 1.1 trillion | about 550 billion |
| 60 bits | about 1.15 quintillion | about 576 quadrillion |
| 80 bits | about 1.2 septillion | about 604 sextillion |
Each step of 20 bits multiplies the pool by roughly a million (2²⁰ = 1,048,576). So 80 bits is about a million times larger than 60 bits, and 60 bits is about a million times larger than 40 bits.
A 40-bit random password falls quickly to an attacker with offline access to a fast hash. A 60-bit password holds up much longer. An 80-bit password moves the search into territory that stays out of reach under most stated assumptions. Those outcomes depend on attack speed, which comes later. The bit count itself only tells you the size of the haystack.
Why Entropy Describes How a Password Was Generated
Entropy belongs to the process that made the password. The finished string has no entropy you can read off it. If you flip a fair coin 60 times and write down the results, the output has 60 bits of entropy, even if it happens to start with ten heads in a row.
The reverse also holds. “Tr0ub4dor&3” looks complicated, but a person picked a word and then applied common substitutions. An attacker models that process directly: dictionary words, capitalized first letters, “0” for “o,” a digit at the end. The real number of choices behind that password is far smaller than its appearance suggests.
A high-entropy password is one that came from a random password generator with many equally likely outputs. When you see a bit count, ask how the password was chosen. The answer to that question sets its strength.
How Do You Calculate Entropy for Random Passwords?
For a password where each character is picked independently and uniformly at random, entropy equals length times log₂ of the character pool size. That formula is accurate for generated passwords and unreliable for passwords people invent, which is why strength checkers use different methods for human-chosen input.
The Formula: Password Length × log₂(Character Pool Size)
Write it as H = L × log₂(N), where L is the password length and N is the character pool size. Two assumptions make it valid:
- Uniform selection: every character in the pool is equally likely at every position.
- Independence: each character is chosen without regard to the others.
A good generator meets both. Common character sets give these values per character:
- Lowercase letters only (26): about 4.70 bits
- Lowercase plus digits (36): about 5.17 bits
- Upper, lower, and digits (62): about 5.95 bits
- All printable ASCII except space (94): about 6.55 bits
- Printable ASCII including space (95): about 6.57 bits
The 94 versus 95 distinction trips up many calculators. Standard printable ASCII has 95 characters, and one of them is the space. Most generators exclude space, which gives a character set of 94. The difference is small per character, but you should use the pool your generator draws from.
Here is a worked example. A 16-character password drawn uniformly from 94 symbols has 16 × 6.555 ≈ 104.9 bits of entropy.
Comparing Character Sets and Lengths in an Entropy Chart
This chart assumes uniform, independent selection:
| Length | 26 (a–z) | 62 (A–Z, a–z, 0–9) | 94 (printable, no space) |
|---|---|---|---|
| 8 | 37.6 bits | 47.6 bits | 52.4 bits |
| 12 | 56.4 bits | 71.5 bits | 78.7 bits |
| 16 | 75.2 bits | 95.3 bits | 104.9 bits |
| 20 | 94.0 bits | 119.1 bits | 131.1 bits |
Read across a row and the gains are modest. Read down a column and they climb quickly. Going from 62 to 94 characters adds about 0.6 bits per character, while adding four more characters adds roughly 24 bits.
That pattern matches what you see in a generator’s options. Enabling more character subsets raises strength a small amount, while increasing length raises it a large amount. A 20-character password of lowercase letters alone (94 bits) beats a 12-character password that uses every symbol (78.7 bits).
Why the Formula Misleads for Human-Chosen Passwords
The formula assumes randomness that people do not supply. “Summer2024!” is 11 characters from a 94-character pool, so the formula reports about 72 bits. An attacker’s first guesses include a season, a year, and an exclamation point, so the realistic count of choices is tiny.
Human-chosen passwords cluster around names, dates, keyboard walks, and familiar substitutions. Cracking tools try those patterns first. A naive password strength meter that just counts character types will praise a weak password and call it a strong password.
Better estimators model how people build passwords. zxcvbn, an open-source estimator first released by Dropbox, matches input against dictionaries, common passwords, dates, sequences, and keyboard patterns, and then estimates the number of guesses. Treat any password strength checker’s output as an estimate of guessability, and remember that it measures a string with no knowledge of how you made it.
One practical caution: do not type a real password into an unfamiliar online checker. You cannot verify where that text goes. Test a similar dummy password, or rely on the meter built into a password manager you already trust.
How Do Entropy and Attack Speed Affect Cracking Time?
Cracking time equals the number of guesses needed divided by the attacker’s guessing rate, so the same entropy can mean minutes or millions of years. The guessing rate depends on whether the attacker is working against a live login or a stolen database, and on how the site stored your password.
Why Online Attacks Differ From Offline Attacks
In online attacks, the attacker sends guesses to a live login page. Rate limits, lockouts, CAPTCHAs, and alerts slow that down to a handful of guesses per second at best, and frequently far fewer. Against online guessing, even moderate entropy holds up, provided the password is not on a common-password list.
Offline attacks are the serious case. When a site’s database leaks, the attacker gets password hashes and can test guesses on their own hardware with tools such as hashcat. No login page stands in the way, so the only limit is how fast their hardware can compute the hash. Plan your entropy targets around this scenario for anything important, because you cannot control whether a service gets breached.
Estimating Average Crack Time Without False Precision
Use this calculation: average time ≈ 2ⁿ⁻¹ ÷ guesses per second. Pick a stated guessing rate and keep it visible, because the answer changes by orders of magnitude with that rate.
At a hypothetical 10 billion guesses per second against a fast, unsalted hash, a brute-force attack would take these average times:
- 52 bits (8 random characters from 94): about 2.6 days
- 60 bits: about 1.8 years
- 80 bits: about 1.9 million years
Treat those as illustrations. Hardware improves, attackers rent clusters, and real guessing rates vary by hash type. A password with 80 bits is extremely costly to brute-force under these assumptions, and that is a statement about cost, with no guarantee attached. Also, crack-time figures apply only to random passwords. A human-chosen password falls to a smart wordlist long before a brute-force search would reach it.
How Password Hashing Changes the Cost of Each Guess
Password hashing is the step a site uses to store a scrambled version of your password, and its design sets the cost of every offline guess. Hashing algorithms fall into two groups:
| Hash type | Examples | Effect on guessing |
|---|---|---|
| Fast general-purpose hashes | MD5, SHA-1, SHA-256 | Built for speed; GPUs test billions per second |
| Slow password hashes | bcrypt, scrypt, Argon2 (Argon2id) | Tunable work factor and memory cost; each guess is deliberately expensive |
A salt is a random value stored with each password hash, so identical passwords produce different hashes and precomputed tables become useless. A pepper is an additional secret kept apart from the database, which helps if only the database leaks.
The difference is large. If a well-tuned bcrypt or Argon2id setup cut an attacker down to a hypothetical 10,000 guesses per second, that same 60-bit password would average about 1.8 million years. You never get to choose a website’s hashing, though. That uncertainty is the reason to give important passwords a comfortable margin of entropy.
How Can You Create Passwords With Enough Entropy?
Let software create your passwords with real randomness, and save memorization for the few secrets you must type yourself. A password generator built on a CSPRNG (a cryptographically secure pseudorandom number generator) satisfies the formula’s assumptions, while your own imagination does not. The practical plan below covers targets, tools, passphrases, and the protections that work alongside entropy.
Choosing Practical Targets for Accounts and Master Passwords
Entropy targets depend on your threat model. These are reasonable working figures, assuming offline attack is possible:
- Ordinary website accounts: about 80 bits or more. A 16-character generated password from 94 symbols gives about 105 bits, which is plenty and costs you nothing since a manager fills it in.
- Master passwords and device encryption: 70 to 80 bits or more in a passphrase you can memorize. These protect everything else, and some vaults can be attacked offline if the encrypted file is stolen.
- API keys and machine tokens: 128 to 256 bits of randomness. No human has to remember them, so there’s no reason to hold back.
Keep these two categories apart. Human passwords trade off strength against memory and typing. Generated API keys face no such trade-off and should come straight from a CSPRNG at full length.
Generating Unique Passwords With a Password Manager
A password manager handles both entropy and uniqueness for you. Managers such as Bitwarden and 1Password include generators where you set the length and character sets, and they store every result so you never have to recall it.
Settings that work well in practice:
- Set length to 16 to 20 characters for normal accounts.
- Keep upper, lower, and digits on; add symbols if the site accepts them.
- If a site rejects symbols, increase length instead. Twenty characters from 62 gives about 119 bits.
- Generate a fresh password for every account and save it immediately.
Length does the heavy lifting. If a site caps passwords at a short length, use the maximum it allows and add MFA.
Calculating Diceware Passphrase Strength by Word Count
A passphrase’s strength comes from how many random words were chosen and how large the word list is. Character count has nothing to do with it. Evaluate the words, never the letters: “correcthorsebatterystaple” is 25 characters, but scoring it as 25 random lowercase letters (about 117 bits) wildly overstates its strength.
Diceware, and the Electronic Frontier Foundation’s EFF Diceware long list, uses 7,776 words (6⁵, one word per five dice rolls). Assuming each word is picked uniformly and independently by real dice or a CSPRNG, each word adds log₂(7,776) ≈ 12.9 bits:
| Words | Entropy |
|---|---|
| 4 | about 51.7 bits |
| 5 | about 64.6 bits |
| 6 | about 77.5 bits |
| 7 | about 90.5 bits |
The independence assumption is strict. If you roll and then swap a word you dislike, or arrange words into a sentence that makes sense, you shrink the pool. For a master password, six or seven true Diceware words is a solid target. Separators and capitalization add little if they follow a predictable rule, so treat them as convenience.
Why Uniqueness, MFA, and Sensible Password Policies Still Matter
High entropy cannot save a reused password. Credential stuffing takes email and password pairs leaked from one site and tries them on others. A 130-bit password reused on a breached forum is effectively zero bits on every other site that uses it.
MFA, or two-factor authentication, adds a second barrier. A stolen password alone no longer opens the account. Turn it on for email, banking, and your password manager first.
Good password policies support all of this. NIST SP 800-63B (Revision 4, finalized in 2025) calls for a minimum of 15 characters when a password is the only authenticator and 8 when it is paired with MFA. It also asks services to allow at least 64 characters, to drop composition rules and forced periodic changes, and to screen new passwords against lists of common or breached ones. Those rules favor length and screening over the old “one uppercase, one symbol” requirements that pushed people toward predictable strong passwords.
Choose Randomness, Length, and a Unique Password Every Time
Password entropy counts the equally likely choices behind a password. Each bit doubles that count, and an attacker needs about half the keyspace on average to find a random secret. The formula L × log₂(N) works only when a generator picks characters uniformly and independently. Human-made passwords score far lower than they look.
Your practical steps follow from that:
- Let a password manager generate 16 to 20 random characters for each account, and never reuse one.
- Use a six- or seven-word Diceware passphrase for the master password, scoring it by words, not letters.
- Treat crack-time estimates as conditional on hashing and guessing rates.
- Turn on MFA for your most important accounts, starting with email and your password manager.
Frequently Asked Questions
How many bits of entropy does a good password need?
For accounts a manager fills in, aim for around 80 bits or more, which a 16-character random password easily exceeds. Master passwords should reach 70 to 80 bits or more, and API keys should use 128 to 256 bits. These targets assume an attacker could guess offline; your own risk may justify more.
Can a password entropy calculator measure a password I made up?
A calculator can estimate guessability, but it cannot know how you created the password, and that process sets the true entropy. Pattern-aware tools like zxcvbn give more realistic results than character-counting formulas. Avoid typing real passwords into an unfamiliar password strength checker.
How much entropy does a 20-character password have?
A 20-character password chosen uniformly at random from 94 printable symbols has about 131 bits of entropy. From 62 letters and digits it has about 119 bits, and from lowercase alone about 94 bits. Those figures apply only if a generator picked each character independently.
Does the xkcd passphrase example really provide strong security?
The xkcd comic assumed four words from a 2,048-word list, which gives 44 bits and is too low for an offline attack today. The idea holds up when you add words: six Diceware words from a 7,776-word list give about 77.5 bits. Words must be chosen randomly, never picked because they sound good together.
Does adding symbols always increase password entropy?
Symbols raise entropy only when a generator chooses them at random as part of the character pool. Expanding the pool from 62 to 94 adds about 0.6 bits per character, much less than adding length. A predictable symbol tacked onto the end of a human password, like a trailing “!”, adds almost nothing.