Password Entropy and How Strong Your Password Really Is
After reading this you will be able to compute a password's entropy in bits by hand, translate that into a realistic cracking time, and spot the common mistakes that make a long password weak.
What a random password buys you
A password is a secret an attacker tries to guess. Its strength is not a feeling, it is a count: how many equally likely passwords could have been produced by the same process. That count is measured in bits of entropy. Each extra bit doubles the number of possibilities, so it doubles the work an attacker must do on average.
Here is the hook. A 12-character password drawn at random from the 94 printable ASCII characters carries about 78.7 bits of entropy. An attacker with a fast offline rig that tries 100 billion guesses per second would need, on average, roughly 3 × 10^11 years to find it. The observable universe is about 1.4 × 10^10 years old. That gap is the whole point.
The word random has to be taken literally. The generator draws each character from crypto.getRandomValues, the same source browsers use for TLS keys. A password you invent yourself is not random in this sense, because your brain reuses patterns, and attackers model those patterns.
When to use a generated password, and when not
Use a generated random password for any account where you can store the result in a password manager. You never have to type it from memory, so length costs you nothing, and full randomness gives you the most entropy per character.
Do not use a character-salad password for something you must memorize and type often, such as the master password to the manager itself, or a disk encryption key. Human memory does badly with random symbols. For those cases a random word passphrase is easier to remember at the same strength.
If you have to memorize it, generate a passphrase instead. Five random words from the EFF list give about 64.6 bits, which is stronger than most sites require, and far easier to recall than a 10-character symbol string.
The entropy formula and why it is a product
When every character is chosen independently and uniformly from an alphabet of size N, and the password has length L, the entropy in bits is:
Here H is entropy in bits, L is the number of characters, and N is the alphabet size (26 for lowercase letters, 62 for letters plus digits, 94 for all printable ASCII). The number of possible passwords is N^L, and taking \log_2 converts that count into bits.
The intuition is that entropy adds while possibilities multiply. Each extra character multiplies the number of possible passwords by N, and adds \log_2 N bits. For a 94-character alphabet, one more character adds \log_2 94 \approx 6.555 bits and multiplies the cracking time by 94. That is why length beats complexity: adding a character to a long password helps more than sprinkling in one new symbol type.
Alphabet size sets the value of each character
The size of the character set decides how many bits every character is worth. Bigger alphabets pay more per character, but the effect is logarithmic, so doubling the alphabet adds only one bit per character.
| Alphabet | Size N | Bits per character (log₂ N) |
|---|---|---|
| Digits only | 10 | 3.322 |
| Lowercase letters | 26 | 4.700 |
| Letters, both cases | 52 | 5.700 |
| Letters and digits | 62 | 5.954 |
| All printable ASCII | 94 | 6.555 |
Notice that moving from 62 to 94 characters, a jump of 32 symbols, buys you only 6.555 - 5.954 = 0.601 extra bits per character. Adding two more characters of length to a 62-symbol password would gain more (11.91 bits) than switching every character to the larger set at the old length.
A worked example with the default settings
16 characters from all printable ASCII
The demo generates a 16-character password using the full 94-symbol printable ASCII set. Reproduce the entropy figure step by step.
- Alphabet size: N = 94.
- Bits per character: \log_2 94 = 6.5546.
- Length: L = 16.
- Entropy: H = 16 \times 6.5546 = 104.9 bits.
- Number of possible passwords: 94^{16} \approx 3.79 \times 10^{31}.
Now the cracking time. Assume a well-funded attacker running 10^11 guesses per second offline. On average they find the password after trying half the space:
Here r is the guess rate per second. That gives t \approx 1.9 \times 10^{20} seconds, or about 6 × 10^12 years. Even if the attacker were a thousand times faster, you would still have billions of years.
Watch length and alphabet fight it out
The relationship H = L \times \log_2 N hides a practical question: to reach a target strength, do you add characters or enlarge the alphabet? Move the sliders and read the answer off the bar.
Reading the crack time without fooling yourself
The tool reports a crack time, but that number depends entirely on the assumed guess rate, and rates vary by many orders of magnitude. Treat the figure as a comparison tool, not a promise.
- Online attack
- The attacker guesses against a live login. Rate limiting caps this at maybe 10 to 100 guesses per second. Even 40 bits (
1.1 × 10^12guesses) resists this for centuries. - Offline fast hash
- The attacker has stolen a database hashed with a fast function like unsalted MD5. Rates reach
10^11to10^12per second on GPUs. This is the assumption behind the numbers above. - Offline slow hash
- The database uses bcrypt or Argon2, deliberately slow. Rates drop to thousands per second, adding roughly 20 to 30 bits of effective protection on top of your password.
Because the difference between these scenarios is larger than any realistic difference in your password length, the honest reading is simple: get past about 80 bits and no guessing attack of any kind is feasible. Below 40 bits you are exposed even to modest offline attacks.
Entropy only counts if the generation was truly random. The bit figure assumes every character was chosen uniformly and independently. A password you picked yourself has far less entropy than its length suggests, because human choices cluster.
Common mistakes that throw away entropy
The formula is only valid when its assumptions hold. Each mistake below breaks an assumption and quietly lowers the real strength.
- Reusing a strong password across sites. One breach exposes every account. A 104-bit password reused on 20 sites is only as safe as the weakest site's storage.
- Turning a random password into a memorable one. If you generate a password and then "fix" it to be typeable, you are substituting your own low-entropy choices for the generator's.
- Counting entropy you did not use. Enabling symbols but then rejecting every password that has an awkward symbol reduces the effective alphabet. Accept what the generator gives you.
- Assuming complexity rules equal strength. A policy demanding one uppercase, one digit and one symbol does not make
Password1!strong. It has perhaps 10 to 15 bits of real entropy because it follows a predictable template.
To sanity-check a password you already have, feed it to a checker that models patterns rather than assuming randomness.
Related tools
The Password Strength Checker estimates entropy for a password you type and warns about dictionary words, keyboard patterns and dates, which the pure formula ignores. When you need something memorable, the Passphrase Generator builds random word strings from the EFF diceware list, where each word adds about 12.9 bits.
Frequently asked questions
How many bits of entropy is enough?
For accounts protected by rate limiting and slow hashing, 60 bits is already very hard to attack. For anything stored offline or high value, aim for 80 bits or more. At 128 bits you match the strength of a symmetric encryption key, which is far beyond any guessing attack.
Why is my long password still rated weak?
A length count is not an entropy count. If the characters come from a small set or follow a pattern, the real entropy is low. aaaaaaaaaaaaaaaa is 16 characters but has almost no entropy, because it is one of very few likely strings.
Does adding symbols matter more than adding length?
No. Adding one character to a 94-symbol password adds 6.555 bits. Adding symbols to a shorter password only raises the per-character value, and the gain shrinks logarithmically. Once your alphabet includes upper, lower and digits, length is the cheaper way to buy bits.
Is crypto.getRandomValues actually secure?
Yes. It is a cryptographically secure pseudorandom generator seeded from the operating system, the same class of source used to generate TLS session keys. It is not Math.random(), whose output can be predicted from a few samples.
Should I change strong passwords regularly?
No, not on a schedule. A password with 80-plus bits will not be guessed, so forced rotation only pushes people toward weaker, patterned choices. Change a password when you have reason to think it was exposed.