Every password strength claim reduces to one fraction: guesses needed, divided by guesses per second. The numerator is about your password; the denominator is about how it gets attacked — and the same password can survive centuries in one scenario and die in seconds in another. Here's what the numbers actually mean, why complex-looking passwords collapse, and how to check yours without typing your real one into anything.
Strength estimators output a guess count — how many tries a smart attacker needs. Crack time is that count divided by attack speed. Four standard speeds cover the realistic scenarios:
| Scenario | Speed | When this is your world |
|---|---|---|
| Throttled online login | 100 / hour | The site locks or delays after failed attempts |
| Unthrottled online | 10 / second | No rate limiting on the login endpoint |
| Offline, slow hash | 10,000 / second | Breach of a database hashed with bcrypt/argon2, done right |
| Offline, fast hash + GPU | 10 billion / second | Breach of a database hashed with something fast like MD5 or SHA-1 |
The jump from scenario one to four is a factor of 360 million billion. This is why "strong enough" is meaningless without a scenario: a password that survives a throttled login forever can evaporate the day its hash leaks from a fast-hashed database. The only scenario you fully control is the last one — assume it, and you're covered.
Because nobody brute-forces character by character. Real cracking runs pattern lists: previous breach dumps, dictionary words, names, years, keyboard walks, and the substitutions everyone makes — a→4, e→3, o→0, plus a trailing "!" or "1". The estimator zxcvbn (first released by Dropbox's security team, now maintained as an open-source fork) models exactly this, which is how it lands on famous results like Tr0ub4dour&3: twelve characters of apparent chaos, recognized as one dictionary word in light l33t plus a year-ish digit run and an obvious symbol. Total: about 412 billion guesses, which at ten billion per second is 41 seconds.
Run the same math on genuinely random strings and the tables turn. Sixteen random characters from all printable ASCII: 16 × log₂(95) ≈ 105 bits of entropy, about 4.4 × 10³¹ possibilities — tens of trillions of years even at fast-hash speeds. The lesson isn't "symbols bad"; it's that symbols only help when they're random, and human-placed symbols almost never are.
Bits are the currency: entropy in bits = log₂(guesses), and every extra bit doubles the work. Working backward from the nightmare scenario:
| Entropy | Guesses (≈) | Offline fast-hash crack time | Feels like |
|---|---|---|---|
| 20 bits | 10⁶ | instant | toast |
| 30 bits | 10⁹ | less than a second | toast |
| 40 bits | 10¹² | ~2 minutes | toast |
| 50 bits | 10¹⁵ | ~1.3 days | bad |
| 60 bits | 10¹⁸ | ~3.7 years | borderline |
| 65 bits | 3.7 × 10¹⁹ | ~117 years | fine for humans |
| 80 bits | 10²⁴ | ~3.8 million years | fine for anything |
| 105 bits | 4.1 × 10³¹ | ~10¹⁴ years | physics joke |
Two anchors worth memorizing: a four-common-word passphrase rates around 65 bits (the classic correct horse battery staple scores 65.5 with the current estimator's dictionaries), and a random 16-character full-ASCII password around 105. Either clears the bar; the difference is mostly whether you can type it on a phone.
Mathematically, always. Entropy from randomness is length × log₂(pool size). Doubling the pool adds one bit per character; doubling the length doubles the total. Twenty random lowercase letters: 20 × log₂(26) ≈ 94 bits. Eleven random characters from all 95 printable ASCII: 11 × log₂(95) ≈ 72 bits. The boring string of lowercase wins by twenty-two bits. This is why NIST's digital identity guidance (SP 800-63B) pushes length over forced composition rules — and why "must contain a symbol" produced a decade of Password1!.
The four-digit PIN, the bank password capped at 12 characters, the site that silently truncates — policy weaknesses you can't fix with cleverness. What you can do: never reuse across sites (so one fast-hash breach doesn't cascade), let a password manager generate and store the long random ones, and turn on two-factor authentication wherever it exists, because it breaks the crack-time math entirely: a stolen password plus a required second factor is a locked door. Our generator handles the first; the second is a settings page away.
Run the estimator locally. Our Password Strength Checker loads zxcvbn's dictionaries into your browser and computes the score, guess count, entropy, and all four crack times in the tab — no transmission, no server. Even so, the best hygiene is to test a variant with the same shape as your real password rather than the real one: same length, same mix of word, number, and symbol. You'll learn the same lesson without ever having typed the crown jewels into a form. For the principles behind the numbers, our longer password strength guide covers dictionaries, hashing, and why managers beat memory.
zxcvbn score, entropy in bits, and crack times at four attack speeds — computed entirely in your browser.
Password Strength Checker →Crack time is a fraction: be on the right side of both halves. Make the numerator huge with length and randomness (60+ bits; four random words or sixteen random characters), and shrink the denominator's importance with unique passwords, slow hashes on the sites you build, and 2FA on the accounts you own. And when a meter says "strong," check whether it counted patterns — because the attacker did.