Two numbers set how much work a brute-force search costs: how many positions your password has, and how many characters could sit in each one. The search space is the pool size raised to the length.
They are not two versions of the same lever, and that is the part almost every password rule gets wrong. One of them can be pulled repeatedly. The other pulls once.
The two numbers that decide everything
The pools come in four sizes. Lowercase alone is 26 characters. Add capitals and it is 52. Add digits and it is 62. Add the symbol set as well and it is 89 — 26 lowercase, 26 uppercase, 10 digits and 27 symbols.
Length is the count of positions. Each position independently holds any character from the pool, so a 12-character password from the 89-character pool has 89 possibilities in every one of its twelve slots.
All of this assumes the characters were drawn uniformly at random. The random number generator covers what uniform drawing actually requires and why an ordinary random function is not enough. If you picked the password yourself, the nominal pool overstates the real search space, sometimes enormously.
The generator's own default is 16 characters with every type enabled. That is a deliberate choice of both inputs, and the rest of this page is about why the first one carries more of the weight.
Why length and complexity are not the same lever
Add one character and you create a whole new position. At the 89-character pool that multiplies the entire search space by 89, and it does so whether the password was short or already long.
Add a character type and you change the pool instead. Going from letters and digits to the full set lifts each position from 62 possibilities to 89. That is a real improvement, but it improves positions that already existed rather than adding one.
So the two levers have different shapes. Length contributes a fresh factor of the whole pool, every time. A bigger pool improves the factors already present, once, and there is no second symbol set to switch on afterwards.
There is a subtler cost to complexity rules too. If you always capitalise the first letter, group the digits, and put a symbol at the end, those characters are not uniform draws from the advertised pool — they are a pattern an attacker can search first.
Eight strong characters against twelve simple ones
Here is the comparison that settles it. An 8-character password using lowercase, capitals, digits and symbols draws on all 89 characters. It carries 51.8 bits of entropy, and the engine gives it 5 hours.
Now take 12 characters of nothing but random lowercase letters. The pool is only 26, but there are four more positions. It carries 56.4 bits, and the engine gives it 6 days.
The plain-looking one wins, and not narrowly: it is 24.2 times harder to search. No capital, no digit, no symbol anywhere in it, and it still beats the password that satisfies every complexity rule on the form.
That is not an argument for lowercase. At equal length the bigger pool wins every time. It is an argument that four extra random positions outweigh moving from a 26-character pool to an 89-character one.
Which means visual complexity is a bad guide to strength. A short string bristling with punctuation can cover less ground than a longer, duller one, and only counting the combinations tells you which.
Both figures also assume genuine randomness inside the stated pool. A memorable lowercase phrase built from ordinary words does not carry 56.4 bits, because those words were never twelve independent draws from 26 letters.
The ladder
| Length | Entropy | Rating | Time to search the space |
|---|---|---|---|
| 6 characters | 38.9 bits | Fair | 2 seconds |
| 8 characters | 51.8 bits | Fair | 5 hours |
| 10 characters | 64.8 bits | Strong | 5 years |
| 12 characters | 77.7 bits | Strong | 39 thousand years |
| 14 characters | 90.7 bits | Very strong | 310 million years |
| 16 characters | 103.6 bits | Very strong | 2 trillion years |
| 20 characters | 129.5 bits | Very strong | longer than the age of the universe |
The top of that table is the part worth staring at. At 6 characters the richest pool the tool offers still yields 38.9 bits and 2 seconds. The alphabet is already maxed out, so nothing but length is left to change.
Restrict the pool to lowercase and the same ladder climbs more slowly, but it does climb. Ten characters gives 47.0 bits and 12 minutes; twelve gives 56.4 bits and 6 days; fourteen gives 65.8 bits and 10 years.
Keep going and even the 26-letter alphabet gets somewhere serious. Sixteen lowercase characters is 75.2 bits and 7 thousand years. Twenty is 94.0 bits and 3 billion years, with no other character type involved at any point.
What one more character actually buys
At the full pool, one more character multiplies the space by 89, which is 6.48 bits. The starting length is irrelevant to that multiplier, because the new position always has the same 89 possible values.
Near the short end that shows up dramatically: 8 to 9 characters moves the estimate from 5 hours to 20 days. Every candidate that existed before now has 89 continuations, which is a different thing from adding a few more guesses.
Further along the same multiplier looks bigger only because the units are bigger. Twelve to thirteen takes 39 thousand years to 3 million years, and sixteen to seventeen takes 2 trillion years to 219 trillion years.
This is what makes length easy to reason about. Once you know the pool, you know exactly what one more random character is worth, without inspecting anything about the characters already there.
And what a symbol buys
Symbols are not a myth, and the honest number is more interesting than either slogan. Going from the 62-character pool to the 89-character pool multiplies the space at every position, and the total gain grows with length.
At 8 characters that is 18.0 times, which converts to about 0.70 of an extra character. At 12 characters it is 76.6 times, or about 1.05 characters. At 16 characters it is 325.1 times, or about 1.40 characters.
So the answer sits between the two slogans people usually pick from. Symbols buy roughly one character. That is not nothing, and it is not the several characters that complexity rules implicitly promise.
If a form demands a symbol, add one and move on. Just do not let the requirement convince you that an 8-character password has been fixed by it, because the arithmetic above says it has not.
Where the crack-time number comes from
Entropy sizes the space; a time estimate also needs a rate. This site assumes 100 billion guesses per second, roughly a well-funded GPU rig against a fast hash. That is a deliberately pessimistic yardstick, which is the honest direction to be wrong in.
It also assumes the attacker finds it after searching half the space on average, so the expected work is 2 to the power of the bits minus one, not the full space.
Worked end to end at length 12 and pool 89: entropy is 12 x log2(89) = 77.71 bits. Expected guesses is 2 to the power of 76.71, about 1.235 x 10^23. Divide by 100 billion a second and you get about 1.235 x 10^12 seconds, printed as 39 thousand years.
The rate is a property of the storage, not of your password. A password held under bcrypt or Argon2 costs vastly more per attempt than this fast-hash model, so treat the column as a way to compare choices rather than a forecast.
What this arithmetic does not cover
Everything above answers one narrow question: how much work is a uniform search of a known pool. Most accounts are not lost that way, and a long password does not touch the other routes.
A reused password does not need searching at all once it is known from somewhere else. Its entropy is irrelevant the moment the exact string exists in another list, which is what makes uniqueness a separate requirement from length.
Phishing bypasses the number entirely. If the password is typed into a convincing page, nobody runs 100 billion guesses a second against anything, and no amount of length makes a disclosed secret unknown again.
Predictable content has the same effect from the inside. Names, dates, substitutions and keyboard runs get tried long before uniform random strings, so a password can be long and still sit in a small, well-travelled corner of the space.
A breach of the site itself exposes records without going near your string, and encoding is not protection either — as the Base64 page puts it, encoded is not encrypted. Two-factor authentication is a separate barrier and worth having on top, not instead.
Common mistakes to avoid
-
Assuming eight characters is fine because it has every type. The full 89-character pool gives 51.8 bits and 5 hours there, against 56.4 bits and 6 days for twelve plain lowercase characters.
-
Treating a required symbol as a substitute for length. At 12 characters, widening the pool from 62 to 89 is worth about 1.05 extra characters — one, not several.
-
Calling symbols useless. They multiply the space 18.0 times at eight characters, 76.6 times at twelve and 325.1 times at sixteen. Real, just not a second lever.
-
Judging by how complicated it looks. A varied short string can cover less space than a duller long one, which is the whole content of that 24.2 times gap.
-
Applying these pools to a password you invented. The 26, 52, 62 and 89 figures assume uniform choice at every position, not a capital at the front and a digit at the end.
-
Reading the crack time as a promise. It assumes 100 billion guesses a second and half the space searched; slower hashing moves it a long way, and reuse or phishing skips the search completely.
Pick the length first, then take the widest pool you can without building a pattern. Every character you add multiplies the space by the whole pool, again and again. A character type pays only once, and how much depends on the type — for the full symbol set, the trade this guide measured, the answer is about one extra character.
Related guide
Putting JSON in a URL
The other end of the utilities shelf: what percent-encoding does to a payload, why the size grows, and which of the two JavaScript encoders you actually want.
Read the guide