Password Strength Calculator
Check a password against predictable patterns and attack scenarios, compare estimated crack times, and keep the candidate in your browser.| Signal | Finding | Why it matters | Copy |
|---|---|---|---|
| {{ row.signal }} | {{ row.finding }} | {{ row.note }} |
| Scenario | Guess rate | Estimated time | Interpretation | Copy |
|---|---|---|---|---|
| {{ row.scenario }} | {{ row.rate }} | {{ row.time }} | {{ row.note }} |
These transparent rates are planning scenarios, not predictions. Real defenses, hash settings, attacker resources, and password reuse can change outcomes substantially.
The logarithmic seconds scale keeps login and breach scenarios readable in one comparison.
Password strength is resistance to guessing, not visual complexity. A short word with a capital letter, a year, and a symbol may satisfy a composition rule while remaining near the front of an attacker's guess list. Length helps most when the added characters are unpredictable. Common words, keyboard runs, dates, repeated blocks, names, brands, and account-specific terms reduce the value of length because an attacker can model those patterns instead of trying every possible character combination.
The attack setting matters just as much as the candidate. A live login may allow only a few guesses before delays or lockout. After a database breach, an attacker can test guesses against stolen password hashes without interacting with the login page. A deliberately slow password hash raises the cost of each attempt; a fast or weakly protected hash can make billions of guesses per second plausible as a planning scenario.
| Signal | What it can show | What it cannot prove |
|---|---|---|
| Pattern-aware score | How early a candidate may appear in a realistic guessing order | That the password is unique or absent from breach data |
| Composition entropy | An upper-bound search space from length and character classes | That a human-created string is random |
| Crack-time estimate | The effect of an assumed guess count and attack rate | The actual hardware, defenses, or time an attacker will use |
A strong password should also be unique to one account. Reuse turns a compromise elsewhere into a direct credential-stuffing attempt, which a strength meter cannot detect. Password managers help by generating and storing long, distinct values, while multifactor authentication adds protection when a password is guessed or exposed. These controls complement strength estimation rather than changing a weak password into a safe one.
Testing a real secret still deserves care. A local assessment avoids sending the candidate to a remote strength service, but screen sharing, browser extensions, clipboard history, shoulder surfing, or saving the result can expose it. For an existing high-value account, it is safer to test a structurally similar dummy value and replace the real password through the account's trusted password-change flow.
How to Use This Tool:
Assess one candidate under the attack situation that best matches the account.
- Enter one candidate in Password. If pasted text contains several lines, only the first line is evaluated.
- Add names, handles, brands, domains, or project words to Known words to avoid. Separate them with commas, semicolons, or new lines so targeted patterns can be flagged.
- Choose a Risk lens. Use a login scenario for a live service or a stolen-hash scenario when planning for a database breach.
- For an offline scenario, adjust Offline slowdown factor only when the password-hashing cost is known. Then read the pattern-aware score together with the selected crack time and the strongest local signal.
Interpreting Results:
The score and selected crack time answer different questions. The score ranks guessability on a five-step scale from Very weak at 0 to Strong at 4. Crack time applies the estimated guess count to one modeled rate. A long time under a locked-down login does not make a candidate safe after a stolen-hash breach.
- Treat a common-password, context-word, email-address, repetition, sequence, or digits-only flag as a reason to replace the candidate rather than decorate it.
- Use composition entropy as an optimistic upper bound. For human-made passwords, the pattern-aware guess estimate carries more weight.
- A Strong result does not check breach corpuses, reuse, account recovery, multifactor authentication, or the service's password storage.
- Compare scenarios rather than reading a crack time as a promise. Real attacker resources and defensive settings are not known.
Technical Details:
The strength model starts with a pattern-aware estimate of guesses and a score from 0 through 4. It separately measures password length, the character classes present, and local warning patterns. The character-class calculation treats lowercase letters as 26 possibilities, uppercase letters as 26, digits as 10, and symbols as 33. That construction is useful as a transparent upper bound, not as a substitute for the pattern estimator.
Formula Core
Composition entropy assumes every character is chosen independently and uniformly from the observed character set.
L is the Unicode character count and N is the combined size of the character classes present. Repeated blocks, dates, dictionary words, and keyboard sequences violate the independence assumption, so the displayed bits can be much higher than the effective guess resistance.
Crack time divides the modeled number of guesses by the chosen guess rate. Offline slowdown divides only the offline rates; it does not affect login scenarios.
G is the pattern-aware guess estimate, R is adjusted guesses per second, and t is seconds. Durations below 0.01 seconds are shown as such; larger values move through seconds, minutes, hours, days, years, and powers of ten years.
| Scenario | Base rate | Slowdown applied |
|---|---|---|
| Locked-down login | 100 guesses/hour | No |
| Weakly rate-limited login | 10 guesses/second | No |
| Stolen slow hash | 10,000 guesses/second | Yes |
| Stolen fast hash | 10 billion guesses/second | Yes |
| GPU cluster breach | 1 trillion guesses/second | Yes |
Rule Core
The selected verdict combines score and crack-time boundaries. Conditions are evaluated in order, so the first match controls the label.
| Verdict | Exact condition |
|---|---|
| High risk in the selected scenario | Score ≤ 1, or crack time < 10⁴ seconds |
| Needs a stronger design | Otherwise, score = 2, or crack time < 10⁶ seconds |
| Reasonable with caveats | Otherwise, score = 3, or crack time < 10⁹ seconds |
| Resilient in the selected scenario | None of the earlier conditions match |
Suggested extra characters use composition-entropy targets of 50 bits for a locked-down login, 60 bits for a weakly rate-limited login, 75 bits for a stolen slow hash, and 90 bits for a stolen fast hash. This recommendation is approximate because it assumes the additional characters are unpredictable. A severe local pattern flag takes priority and recommends replacing that pattern instead.
Privacy and Limitations:
The password and context words are evaluated in the browser and are not sent to a strength-checking service. The assessment does not query breach databases or store a history of tested candidates. Local processing cannot protect a secret from other software or people with access to the device.
- Do not treat a crack-time estimate as a guarantee of survival time.
- Do not paste a live password while screen sharing or on an untrusted device.
- Replace reused or exposed passwords even when their local score is high.
- Use a password manager to create a unique value and enable multifactor authentication where available.
References:
- Digital Identity Guidelines: Authentication and Authenticator Management, National Institute of Standards and Technology, July 2025.
- Low-Budget Password Strength Estimation, Dropbox.