There's no single answer to this question, and any tool or article that gives you one number without saying which attack it assumes is skipping the part that actually matters. password123 is cracked in well under a second. A truly random 16-character password can take longer than the universe has existed, under the exact same word "crack". The gap between those two isn't exaggeration — it's what this post walks through, with the actual numbers.
The three things that decide the answer
"How long to crack a password" collapses three separate questions into one, and each has its own answer:
- Is it already on a list an attacker tries first? Billions of real passwords from past breaches, plus every predictable variation of common words, get tried before anything resembling brute force starts. If a password is on that list, its crack time isn't a keyspace calculation — it's however long it takes to reach that entry, usually seconds.
- Where is the attack happening? An attacker guessing against a live login form is throttled by rate limiting to a handful of attempts per second. An attacker who stole a database of password hashes and is guessing offline, on their own hardware, faces no such limit — and how fast that goes depends entirely on how the passwords were stored in the first place.
- How random is it, really? A password's actual strength is measured in entropy — bits of real randomness — not how complicated it looks.
Tr0ub4dor&3looks complex and is still a fairly predictable transformation of a dictionary word; a 12-character string generated by Password Generator looks plainer and is astronomically harder to guess, because every character was chosen independently at random instead of following a pattern a person would pick.
Most cracked passwords never need brute-force math at all
Before trying every possible combination, any competent attacker tries the passwords people actually use: the top entries from billions of leaked credentials, common words with the predictable substitutions people make (p@ssword, P@ssw0rd1), keyboard walks (qwerty123), and names or dates specific to the target. password123 isn't cracked by working through a 62-character keyspace one guess at a time — it's near the top of every breach-derived wordlist in existence, so it's found in the first few thousand guesses, regardless of how the password is stored or how fast the attacker's hardware is. This is exactly why NIST Password Guidelines Explained requires checking new passwords against a breach corpus at the moment they're created — it removes the passwords this kind of attack finds instantly, before the keyspace math below ever becomes relevant.
Once it's not a dictionary hit: guess rate is everything
For a password that isn't a known or predictable value, the time to find it by working through the remaining possibilities comes down to how many guesses per second an attacker can sustain — and that number spans eleven orders of magnitude depending on where the attack happens:
- Online, rate-limited (~10 guesses/sec) — a real login form with reasonable throttling. Slow by construction, regardless of the password.
- Offline, fast hash (~100 billion guesses/sec) — a leaked database where passwords were stored with a raw, general-purpose hash like MD5 or unsalted SHA-256, cracked on a single consumer GPU. See Password Hashing Explained for why this failure mode is so common and so damaging.
- Offline, slow hash (~10,000 guesses/sec) — the same leaked database, but stored properly with bcrypt or Argon2id at a reasonable cost factor. Six to seven orders of magnitude slower, for the exact same underlying attack.
The middle scenario is the one that should worry you most as a password owner, since it's entirely outside your control — it depends on a system you don't operate having made the right storage decision.
Crack time by password style
Running the numbers — keyspace divided by two, divided by guess rate — across a few realistic password styles shows just how much the shape of a password matters, not just its length:
| Password style | Online, rate-limited | Offline, fast hash | Offline, slow hash |
|---|---|---|---|
A top-breached password (password123) | Seconds — found by dictionary lookup, not brute force | ||
| 8 random lowercase letters | ~3.3 centuries | ~1 second | ~121 days |
| 8 random mixed-case letters + digits | ~3,459 centuries | ~18.2 minutes | ~3.5 centuries |
| 12 random mixed-case letters + digits | 5.1 × 10¹⁰ centuries | ~5.1 centuries | 5.1 × 10⁷ centuries |
| 12 random, full character set (incl. symbols) | 8.6 × 10¹² centuries | ~856 centuries | 8.6 × 10⁹ centuries |
| 4-word random passphrase | ~57,928 centuries | ~5.1 hours | ~57.9 centuries |
| 16 random mixed-case letters + digits | 7.6 × 10¹⁷ centuries | 7.6 × 10⁷ centuries | 7.6 × 10¹⁴ centuries |
Two things stand out. First, the top row: no amount of keyspace math matters if the password is simply known in advance. Second, the middle column — offline, fast hash — is where password choice actually earns its keep; the online and slow-hash columns are already comfortable at 8 random characters, but the fast-hash column doesn't become genuinely safe until well past 12. For the same table extended across every length and character set, not just the rows above, see Minimum Password Length Recommendations, which uses this exact formula to explain why NIST's specific numbers land where they do.
Why two 12-character passwords can have wildly different real answers
Password12! and a 12-character string from a CSPRNG both satisfy "12 characters, mixed case, digit, symbol" — and have almost nothing else in common. Password12! follows a pattern real people use constantly (capitalize the first letter, digits and a symbol at the end), which puts it near the front of a targeted dictionary attack rather than deep in a 78-bit keyspace. The table above assumes every character was chosen independently and completely at random, which is only true for a machine-generated password — a person-chosen one almost never actually reaches it, no matter how it scores against a composition rule. Password Entropy Calculator checks a real password against exactly this gap: it computes the raw entropy number and separately flags common weak patterns — leetspeak substitutions, keyboard runs, sequential characters — that the keyspace formula alone can't see.
Common mistakes
- Trusting a crack-time number with no stated assumptions. "This password would take 3,000 years to crack" means nothing without knowing the assumed guess rate — the same password can be centuries away under one scenario and minutes away under another.
- Assuming length alone protects you. Length only helps against the attack you can't control the storage for. If a service hashes passwords properly, a shorter password is already safe against realistic attacks; if it doesn't, no reasonable length fully compensates on its own.
- Confusing composition rules with real randomness. A password that satisfies "uppercase, digit, symbol" can still be highly predictable — see the section above. Composition requirements are a NIST SHALL NOT for exactly this reason; What Makes a Strong Password Policy? covers what to require instead.
- Ignoring reuse. None of this math matters if the exact same password already leaked from a different, unrelated site — see Credential Stuffing Explained for the attack that skips cracking entirely and just tries a known-correct password somewhere new.
FAQ
So how long would it actually take to crack my password?
Enter its length and character set into Password Cracking Time Estimator, or paste the actual password into Password Entropy Calculator for the same numbers plus a check for common weak patterns. Both run entirely in your browser and send nothing anywhere.
Does adding a symbol help more than adding a character?
Usually not. Adding one symbol to an 8-character alphanumeric password raises the pool from 62 to 95 characters — about 5 extra bits of entropy. Adding four more random characters from the same 62-character pool adds roughly 24 bits. Past one or two character classes, length does almost all of the remaining work.
Why do different online calculators give me wildly different answers for the same password?
They're assuming different guess rates — often without saying so. A tool assuming an offline fast-hash attack will report a far shorter time than one assuming a rate-limited login form, for the identical password. Always check what attack scenario a number assumes before comparing it to another tool's.
Does two-factor authentication make any of this irrelevant?
It makes a successful guess insufficient on its own, which is a real and significant improvement — but it doesn't change how long the guessing itself takes, and a compromised password is still useful to an attacker for other things (password reuse elsewhere, for one). See Multi-Factor Authentication Explained for what MFA does and doesn't cover.
Try it yourself
Password Cracking Time Estimator runs this exact calculation for any length and character set. Password Entropy Calculator checks a real password you already have, weak-pattern detection included. And Password Generator creates a new one at whatever length the numbers above talk you into. All three run entirely in your browser.