Password Strength Calculator

A password strength result is really a guess-resistance estimate. It asks how soon a realistic attacker might try the secret, not whether the string looks complicated at first glance. A password such as River2026! satisfies a classic complexity rule, yet it still carries a word, a year, and a predictable suffix. A longer random secret with fewer character categories can be much harder to reach because it gives away less structure.

Several terms matter before a strength number is useful. Length expands the search space, but human patterns decide where the password appears in the guessing order. A breach changes the problem again because attackers may test guesses against stolen hashes without going through the account sign-in form. Slow password hashing, login throttling, and multifactor authentication can reduce risk, while reuse can make even a strong password fail after another service leaks it.

Guess count

The estimated number of tries needed before the password appears in the attacker's list.

Entropy

A bit-based search-space estimate. It is helpful for random strings and optimistic for human-made ones.

Attack rate

How many guesses can be tested in a given time, from a throttled login to a fast breach-cracking setup.

Context word

A personal, site, company, domain, or project word that targeted guesses are likely to try early.

Password meters became more useful when they stopped treating uppercase, lowercase, digits, and symbols as the whole story. Modern guidance favors longer memorized secrets or password-manager generated values, checks against common and compromised choices, and rate limits that slow repeated guessing. Those controls work together. A meter can reject a weak idea, but it cannot prove that the account provider stores passwords well or that the same secret is not already reused elsewhere.

The most common mistake is to read a favorable score as permission to reuse a password. Reuse makes the password depend on every site where it has ever been entered. The healthier rule is one unique secret per account, with extra attention for email, financial, administrator, cloud, and recovery accounts because those accounts can unlock others.

A strength estimate also has a narrow field of view. It can point out short length, dictionary words, dates, repeats, keyboard walks, and context terms. It cannot detect every breach corpus, phishing risk, malware, shoulder surfing, weak recovery workflow, or poor server storage. Treat the result as a way to improve a candidate before use, not as a complete account-security audit.

How to Use This Tool:

Check one candidate password at a time, then read the verdict together with the pattern findings and crack-time rows. The calculator evaluates the first line only, so pasted lists need to be split before each password can be judged.

1. Enter the candidate password. Use the show or hide control according to your screen privacy; the visible result updates from the first non-empty line.
2. Choose the Risk lens that matches the threat you care about. Pick a login lens for repeated sign-in attempts and a stolen-hash lens for breach resistance.
3. Set Offline slowdown factor only when you are modeling a slower hash for breach rows. The value is rounded to a whole number of at least 1 and does not change login-form rows.
4. Add names, handles, domains, company terms, product names, or project words to Known words to avoid when targeted guessing is realistic.
5. Review Strength Assessment, Attack Outlook, Pattern Flags, and Upgrade Plan before deciding whether the candidate is worth keeping.

If the extra-lines warning appears, later lines were ignored. Check each candidate separately so the score, verdict, and pattern flags refer to the password you actually plan to store.

Interpreting Results:

Decision is the fastest read. Replace now means the selected scenario, low score, or a severe pattern makes the candidate unsuitable. Upgrade before use means the password has a weakness that should be fixed before relying on it. Solid if unique and Strong if unique are favorable only when the password is new for this account.

Pattern-aware score runs from 0 to 4. It accounts for common words, keyboard paths, dates, repeated segments, straight sequences, email-like strings, context words, and short length. Composition upper bound is a separate bit estimate based on length and detected character space. When the two disagree, trust the pattern findings and pattern-aware score before the optimistic bit count.

Attack Outlook turns the guess estimate into time under several rates. The selected risk lens is highlighted, while the other rows show how quickly the same password changes meaning between strict login throttling and breach-style cracking. Crack Time Ladder uses the same rows to make the gap between scenarios easier to compare.

No obvious pattern flag means only that the current checks did not find a listed pattern. It does not confirm that the exact password is absent from breach lists, unreused, safe to share, or protected by multifactor authentication and strong server-side storage.

Technical Details:

Password strength estimation joins two different ideas. A search-space calculation asks how many strings are possible from the detected length and character types. A guess-order calculation asks where the actual password would appear when attackers try dictionaries, leaked-password patterns, dates, keyboard walks, substitutions, and personal context before random brute force.

The composition estimate is useful as a ceiling, especially for random strings. It becomes too generous when the password contains structure. A 12-character string built from lowercase letters and digits can have a respectable bit estimate, yet a word plus a year may be tested far earlier than a uniformly random 12-character draw from the same character space.

Formula Core:

Rule Core:

As a substitution example, a 12-character password that uses only lowercase letters and digits has S = 36, so the composition upper bound is 12 × log2(36), about 62 bits. If the same visible string contains a word and a recent year, the practical guess estimate can drop sharply because the attacker does not need to search the full random space.

Limitations and Privacy Notes:

No password meter can confirm that a password is absent from every breach corpus, unused on every other site, or protected by a service with strong storage and rate limits. It also cannot account for phishing, malware, recovery-channel weakness, reused security answers, or an attacker who already knows personal details about the account holder.

The password value is evaluated in the browser and is omitted from generated CSV, document, JSON, and share-link data. Normal page resources may still be requested by the browser, so avoid testing a high-value production secret unless your policy allows it. A safer practice is to test a structurally similar draft, then create and store the real password in an approved password manager.

Only the first line is analyzed. This prevents a pasted list from being merged into one score, but it also means every later line still needs its own check.

Advanced Tips:

• Use the stolen-hash lenses for administrator, email, recovery, database, cloud, and financial accounts because breach resistance matters most when one account can unlock others.
• Raise Offline slowdown factor only when you have a defensible reason to model slower password hashing; do not use it to make a weak candidate look acceptable.
• Put service-specific words in Known words to avoid, including the domain, company name, product name, user handle, team name, and project code.
• When Composition upper bound looks strong but Pattern Flags finds a severe issue, change the structure rather than swapping one character for a symbol.
• Use Crack Time Ladder to compare risk lenses, then decide from the scenario that matches your actual threat rather than the most favorable row.

Worked Examples:

Company2026! has uppercase, lowercase, digits, and a symbol, but the shape is predictable. Adding company to Known words to avoid should make the context problem visible, and the recent year can also trigger a pattern flag. The better fix is a different secret, not another punctuation mark.

A random-looking 11-character string can be a borderline case under a breach lens. It may avoid dictionary and date flags, but the selected crack-time row can still be too short for a high-value account. Adding several random characters usually helps more than substituting @ for a because every added position expands the search.

A long unique password-manager value or an unrelated generated passphrase is a healthier result. If it has no context words, no severe pattern flags, and a favorable selected crack-time row, the remaining work is operational: store it safely, use one secret per account, and replace it immediately if exposure is suspected.

FAQ:

Glossary:

Attack rate

The number of password guesses a scenario can test in a given time.

Composition upper bound

An optimistic bit estimate based on password length and detected character categories.

Context word

A user-supplied word that should be treated as predictable, such as a name, domain, brand, handle, or project term.

Crack time

The estimated time to try the expected number of guesses at a scenario's modeled rate.

Pattern-aware score

A 0 to 4 strength label that accounts for common password structures as well as length.

References:

• NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management, National Institute of Standards and Technology.
• Password Storage Cheat Sheet, OWASP Cheat Sheet Series.
• Credential Stuffing Prevention Cheat Sheet, OWASP Cheat Sheet Series.
• zxcvbn: Low-Budget Password Strength Estimation, Daniel Lowe Wheeler, USENIX Security 2016.