How To Read A Password Strength Estimate

A password-strength checker puts a number on a question that is otherwise hard to see: how much guessing might a password require? That number can help explain the difference between a short test string and a longer one. It does not certify an account's security, and it should not be read as a clock counting down to compromise.

The Password Strength Checker provides an estimate for exploring that question. Use synthetic strings, not current account passwords, recovery codes or other secrets. A published example is test data, never a password to adopt.

What This Checker Computes

The checker starts with length times log2 of a character pool: 26 for lowercase, 26 for uppercase, 10 for digits and 33 for symbols, added when those character groups appear. It caps the estimate at 20 bits when it finds one of ten listed common substrings and reduces it by 20% for three or more repeated characters. It also displays warnings for year endings and short strings. Those are limited heuristics, not a full dictionary or breach-list test.

Its attack scenarios assume 100 guesses per second online and ten billion per second offline, using half the estimated search space as expected guesses. The formatter divides year counts by 1,000 at that threshold while still labeling them years, so very large displayed durations are not reliable. Even correctly formatted durations remain model outputs, not validated predictions. The input is visible text: another reason to use synthetic strings only.

An Estimate Needs Assumptions

A crack-time display combines assumptions about the candidate password with assumptions about an attack. Change either and the answer changes. Online guessing against a service with rate limits differs from offline guessing against stolen password hashes. The hash algorithm, its settings, an attacker's hardware and their choice of guesses all affect the result.

That is why a long-looking time is not a promise. It describes a scenario under a model, not the time a specific attacker will take. A shorter-looking estimate can be useful feedback, but the exact duration is not a measured fact about your account.

Appearance Is Not Randomness

Two strings with the same length and character types can have very different origins. One might come from uniform random sampling. Another might be a familiar word with a year and punctuation added. Counting characters alone cannot prove how a string was generated or how early a guessing tool will try it.

Use the checker to explore its own feedback. Start with an invented test string, extend it, and compare the display. Then try another synthetic shape. If a change affects the estimate, that shows what the model responds to. If it does not, that does not prove the two strings are equally resistant to every attack.

Account Safety Goes Beyond Guessing

A password can be exposed without anyone guessing it: phishing, malware and an unrelated breach involving a reused password are different problems. A strength estimate does not test those risks, check the site's storage practices, or establish that a password has not already appeared in a breach.

For real accounts, use a dedicated password manager to generate and store a unique password for each account. Enable multi-factor authentication where supported. MFA adds protection, but it does not prevent every attack. Follow the account provider's security guidance when you suspect exposure rather than treating a favorable checker score as evidence everything is fine.

Try The Estimate Without Sharing Secrets

Open the checker with throwaway test data. Change one property at a time and read the resulting estimate as model feedback. Do not paste a real password to "prove" it is safe, and do not reuse a generated demonstration string on an account.

When the experiment is finished, make any real password change through your password manager and the account's own settings. The checker is an educational comparison, not the place to validate live credentials.