zxcvbn scoring, entropy in bits, and crack time at four attack speeds — all local
| Attack scenario | Speed | Time to crack |
|---|---|---|
| Online, throttled login form | 100 / hour | — |
| Online, no throttling | 10 / second | — |
| Offline, slow hash (bcrypt) | 10,000 / second | — |
| Offline, fast hash + GPU | 10 billion / second | — |
*Character-pool entropy is the naïve "random string" figure — L × log₂(pool) for the character classes you used. zxcvbn's guess count is the honest one: it accounts for words, names, dates, repeats, sequences, and keyboard patterns. When the two disagree, believe zxcvbn.
| Password | Score | Guesses | Bits | Offline fast (10¹⁰/s) | Offline slow (10⁴/s) |
|---|---|---|---|---|---|
password | 0 | 3 | 1.6 | instant | instant |
qwerty12345 | 1 | 1,797 | 10.8 | instant | instant |
Summer2024! | 2 | 10,010,000 | 23.3 | instant | 17 minutes |
Danny2000! | 3 | 108,091,600 | 26.7 | instant | 3 hours |
Tr0ub4dour&3 | 4 | 411,604,000,000 | 38.6 | 41 seconds | 1.3 years |
YVD4!n8Q#pLz2%Wq | 4 | 10¹⁶ | 53.2 | 12 days | centuries |
correct horse battery staple | 4 | 5.27 × 10¹⁹ | 65.5 | 167 years | centuries |
Note the trap in row five: score 4 with only 38.6 bits. The 0-4 score compresses everything from 10¹⁰ guesses upward into one bucket, so a "4" can mean twelve days or a thousand centuries — read the crack-time column, not the badge.
| Score | Guesses below | Meaning | Example above |
|---|---|---|---|
| 0 | 10³ | Too guessable — rejected by any sane policy | password |
| 1 | 10⁶ | Very guessable — trivial for offline attacks | qwerty12345 |
| 2 | 10⁸ | Somewhat guessable — fine with rate-limiting, not for valuables | Summer2024! |
| 3 | 10¹⁰ | Safely unguessable — solid for most accounts | Danny2000! |
| 4 | 10¹⁰ and up | Very unguessable — but check actual crack time (see note above) | correct horse battery staple |
Character-counting strength meters lie to you. They see "12 characters, upper, lower, digit, symbol — strong!" while an attacker's first guesses are dictionary words with common decorations, and "Tr0ub4dour&3" is in the first billion tries. zxcvbn — first released by Dropbox's security team and maintained today as an open-source TypeScript fork — estimates strength the way crackers work: it matches your password against dictionaries (common passwords, English words, names), keyboard adjacency patterns, sequences, repeats, and dates, then computes the cheapest way to guess it.
The engine returns a guess count, and everything on this page derives from it. Entropy in bits is log₂ of the guesses — 38.6 bits ≈ 412 billion possibilities. Crack time is guesses ÷ rate for each of the four standard scenarios, from a login form that allows 100 tries an hour to an offline rig with fast hashes doing 10 billion per second. The naïve character-pool figure (length × log₂ of pool size) is shown for contrast: for truly random strings the two agree, and for human patterns they diverge exactly as far as your password is predictable.
Type a variant of your real password — same shape, different content — and read two numbers: the offline-fast crack time (the "database breach" scenario) and the entropy. Then look at the token chips: they show how the engine broke your password apart, which is precisely the recipe an attacker would use. The feedback box suggests the specific fix, and it usually says "add another word," not "add another symbol."
Start with Summer2024! — the estimator finds "Summer" as a dictionary word, "2024" as a date, and the "!" as one of three obvious closers: 10,010,000 guesses, 23.3 bits, score 2. Offline with a slow hash that's 17 minutes; with a fast hash, instant. Replace the idea entirely with correct horse battery staple: four common words the engine can't compress below 5.27 × 10¹⁹ guesses — 65.5 bits, 167 years even at 10 billion guesses per second. Or go random: sixteen characters from all printable ASCII carry 16 × log₂(95) ≈ 105.1 bits, about 4.4 × 10³¹ possibilities, cracking in the tens of trillions of years at fast-hash speeds.
When you've found a shape that holds up, generate it properly with our Password Generator rather than inventing one — humans are terrible sources of randomness, and the estimator knows it.
Strength is the number of guesses an attacker needs, which a good estimator derives from what your password is made of — dictionary words, names, dates, keyboard patterns, and l33t substitutions all collapse the possibilities. This checker shows the estimate as a 0-4 score, an entropy figure in bits, and crack times at four attack speeds, from throttled online login attempts to a fast offline rig doing ten billion guesses per second.
Nothing is transmitted — the estimator runs as JavaScript in your tab and there is no server involved. That said, the healthiest habit is to never type a real password into any web page, including this one: test a variant with the same shape instead (same length, same mix of word, name, number, and symbol) and the score will be representative.
Because attackers don't guess character by character — they guess patterns. The estimator recognizes "Tr0ub4dour" as a dictionary word with l33t substitutions and ranks the whole password at about 412 billion guesses: roughly 41 seconds against a fast offline attack. Complexity theater (swapping a for 4) adds almost nothing once the base word is known.
Against a serious offline attack (10 billion guesses per second), you want the crack time in centuries, which starts around 60 bits. A truly random 16-character password from all printable ASCII carries about 105 bits; a four-word passphrase made of common words lands near 65 bits. Anything under 30 bits falls in seconds to minutes offline.
Length, by a wide margin, and the mathematics is unromantic: twenty random lowercase letters carry about 94 bits, while eleven fully random characters from the entire printable ASCII set carry about 72 bits. A longer simple password beats a shorter complex one. That's also why NIST's digital identity guidance favors length over mandatory composition rules.
Four standard scenarios: 100 guesses per hour for a throttled login form; 10 per second for an unthrottled online attack; 10,000 per second for a slow hash like bcrypt properly configured; and 10 billion per second for a fast hash attacked offline with GPU hardware. The first two are what website logins face; the last is the worst case when a leaked database used fast hashing.