Password Crack Time Calculator
See how long a password policy, or one password, takes to brute-force at several attacker speeds, from a throttled login to a GPU farm.
Runs in your browser Your input never leaves your device.
This shows the weakest password the policy still allows: the shortest length, drawn randomly from the whole character pool. Real passwords people choose are usually far weaker.
The password stays in your browser. This is the theoretical maximum, assuming the characters are random. A word, a name or a common substitution is guessed far sooner — use the strength test and pwned password check for that.
| Attacker | Average time to crack |
|---|
Average time is half the keyspace at each guessing rate. The rates are rough orders of magnitude for illustration, not a promise about any real system.
Report a problem with this tool
About this tool
This answers a question a password policy should but rarely does: how long would the weakest allowed password hold up? Choose a minimum length and which character types are allowed (lowercase 26, uppercase 26, digits 10, symbols 33), and it works out the character pool, the entropy in bits (length x log2(pool)) and the average time to brute-force it at five attacker speeds: a rate-limited login (about 10 guesses a second), an unthrottled API (a thousand), an offline leak hashed with a slow algorithm like bcrypt or argon2 (ten thousand), an offline leak with a fast hash and one GPU (ten billion), and a GPU farm (a trillion). The policy view uses the worst case the policy still permits: the shortest length, drawn at random from the whole pool. The second tab measures one specific password the same way. Average time is half the keyspace, because on average an attacker finds a random secret halfway through. All of the arithmetic is done in logarithms, so even times longer than the age of the universe are reported without overflow, and the result never goes down when you make the password stronger. We cross-checked the entropy and the crack-time figures against the same formulas in Python. Two honest limits: the attacker speeds are rough orders of magnitude, not a promise about any real system; and the figures assume truly random characters, so a real password built from words, names or simple substitutions is guessed far sooner than the number here suggests. For that kind of estimate use the password strength test and the pwned password check on this site. Nothing you type is sent anywhere.
How to use it
- Pick the policy tab, set the minimum length and tick the allowed character types.
- Read the entropy and the crack time for each attacker.
- Or switch to the password tab to measure one password.
- Aim for times that stay long even in the offline, fast-hash rows.
Example
The weakest 8-character password the policy allows is not safe against an offline attack.
Policy: minimum length 8, lowercase + uppercase + digits (pool 62)
About 48 bits. Offline fast hash (one GPU): a few hours. Add symbols and length to push it to centuries.
Common problems
- The time seems far too long for a real password
- The figure assumes random characters. A password made of words or names has far less entropy than its length suggests; use the strength test for a realistic score.
- Which attacker speed should I trust?
- For a leaked database, the offline rows matter most: slow-hash if you use bcrypt or argon2, fast-hash or GPU farm if you use MD5 or SHA-1. For an online service, the throttled row is closer.
- My policy allows symbols but users pick none
- Allowing a character type is not the same as requiring it. The policy view shows the weakest allowed password; if symbols are optional, test with them unticked too.