What this estimates
An educational look at brute-force complexity: pick a length and a character set, and see the resulting keyspace and a rough time-to-crack under three different attack scenarios. No real password required — this is for understanding how length and character variety trade off, or for planning a policy requirement ("what would a 12-character alphanumeric minimum actually hold up against?"), not for auditing one specific password.
Have an actual password you want checked instead — including a scan for common weak patterns a pure keyspace number can't see? Password Entropy Calculator does that.
The formula, and its one big assumption
The keyspace is poolSizelength — every possible string of that length drawn from that character pool. In bits, that's length × log₂(poolSize). The entire calculation rests on one assumption: every character was chosen independently and completely at random from the pool. That's exactly true for a password generated by a CSPRNG (see Password Generator), and it's the reason this tool works from a hypothetical length/charset rather than real text — a person-chosen password almost never actually achieves this theoretical maximum, since people don't pick characters uniformly at random.
Where the crack-time numbers come from
The three attack scenarios use illustrative, order-of-magnitude guess rates for 2025-era hardware, not a precise benchmark of your specific situation:
- Online, rate-limited (10 guesses/sec) — a real login endpoint with reasonable rate limiting.
- Offline, fast unsalted hash (~100 billion guesses/sec) — a single high-end GPU cracking a leaked MD5 or unsalted SHA-256 hash. A real RTX 4090 benchmarks at roughly 150 billion MD5 guesses/second in hashcat.
- Offline, slow hash (~10,000 guesses/sec) — bcrypt or Argon2 used properly, which is precisely why these algorithms exist: the same RTX 4090 only manages around 180,000 bcrypt guesses/second even at a low cost factor, and a properly configured higher cost factor cuts that further.
The gap between the second and third row is the entire reason password hashing algorithms exist instead of just using a general-purpose hash function.
FAQ
Is anything sent anywhere?
No — everything here is arithmetic that runs entirely in your browser.
Why is there no field for an actual password?
That's deliberate — this tool is for the hypothetical "what would this length and charset hold up against" question. For a real password, use Password Entropy Calculator, which also checks it against common weak patterns (leetspeak substitutions, keyboard runs, sequential runs) that this pure keyspace number can't detect.
My policy requires 12 characters with mixed case and digits — is that actually strong?
Enter 12 for length and check lowercase, uppercase, and digits to see this tool's answer — but remember it's the theoretical best case. A real population of users picking their own 12-character mixed-case-and-digit passwords will cluster heavily around predictable patterns (a capital first letter, digits at the end) that make the real-world average far weaker than this number suggests.