Testing password strength means applying a consistent set of checks to a proposed secret and reading the resulting label as guidance, not as a guarantee of safety. A reasonable local test focuses on length, the diversity of character types, and a small set of obvious weaknesses such as repeated chunks or simple sequential runs. The label is useful only when you can see what was checked, what was skipped, and what the score deliberately leaves out. The Password Strength Checker runs entirely in your browser, never uploads the value you type, and reports its length, character-group count, pattern flags and recommendations on the same page so the logic is auditable. Treat that local label as one input to a larger decision: a unique password stored in a manager, a breach-aware blocklist screen run by the account provider, and multi-factor authentication turned on for the accounts that matter most.
What a Password Strength Test Actually Checks (and What It Can't)
A typical strength meter is not trying every character combination against your secret. Instead, it applies a fixed set of heuristic rules and reports a label. Those rules usually cover length, the number of broad character groups present, and a small set of obvious weaknesses such as repeated chunks or sequential runs. The Password Strength Checker follows that tradition but adds two things most meters hide: it counts Unicode code points so an emoji is one character, not two UTF-16 units, and it shows every threshold it applies in plain language on the same page.
The same transparency makes it easy to spot the gaps. The meter does not estimate entropy in bits, does not download a breach corpus, does not send a partial hash to a remote service, and does not recognize every keyboard walk, quote, song lyric, name, date or leaked password. The pattern check is intentionally narrow. It flags a chunk of up to four code points repeated at least three times, or a run of four code points increasing or decreasing by one. A "No pattern detected" result only means those two checks did not fire, which is not the same as a clean bill of health.
How to Test Password Strength Locally with the Password Strength Checker
Use the Password Strength Checker to get a private, NIST-aligned review of a candidate secret without sending it to a server. The tool runs entirely client-side, so the value you paste never reaches a network endpoint. Follow these steps in order.
- Open the Password Strength Checker and locate the input field at the top of the page.
- Type or paste the candidate password. The characters stay hidden until you press Show, so you can review the rules before exposing the value on screen.
- Read the reported length first. Length is the single biggest factor in the label, because current NIST guidance treats passwords shorter than 15 characters as weak when length is the only authentication factor.
- Check the descriptive character-group count. The note lists lowercase, uppercase, digits, symbols, whitespace and non-ASCII characters, but it does not require one of each, so a long lowercase passphrase is not penalized for being uniform.
- Look at the pattern flag. A short chunk repeated three or more times, or a four-character monotonic run, caps the label at Fair regardless of total length.
- Read each recommendation line. The recommendations point at length, uniqueness, manager use and MFA rather than at formulaic substitutions.
- Once the label reaches Good or Strong and no pattern fires, copy the value into a password manager entry, then run the account provider's own blocklist check and turn on MFA before you submit the new secret.
How the Five-Level Score Is Built
The label is built from two inputs only: the number of Unicode code points in the value, and a boolean for whether the narrow pattern check fired. The thresholds below are the published boundaries and they match what the page reports on every load.
| Length in code points | Pattern detected? | Reported label |
|---|---|---|
| 0 (empty) | — | 0 (no label) |
| 1 to 7 | any | Weak |
| 8 to 14 | yes | Fair (capped) |
| 8 to 14 | no | Fair |
| 15 to 19 | no | Good |
| 20 or more | no | Strong |
A value of 15 to 19 characters with a simple pattern is still capped at Fair, because the pattern rule overrides the length band. A value of 20 or more characters is treated as Strong only when no pattern fires; the label covers documented local checks, not the broader question of whether an attacker would guess the value. NIST SP 800-63B explicitly notes that estimating entropy for user-chosen passwords is difficult, which is why this page avoids advertising a cracking-time guarantee and reports the bands as feedback rules instead.
Why Local Feedback Is Not the Same as a Breach Check
A local meter that runs in the browser has no way to know whether your proposed secret has appeared in a published leak. The Password Strength Checker does not download a blocklist, does not query a remote breach service, and does not transmit a partial hash. That design is deliberate: it keeps the value on your device, but it also means the page cannot tell you that a familiar seasonal string is one of the billions already exposed in public dumps. The OWASP Authentication Cheat Sheet recommends that production verifiers compare the complete proposed password with a current blocklist of common, expected and compromised values, and that step belongs to the account provider, not to a browser-only tool.
This gap is the reason the page recommends following the account provider's own breach or compromised-credentials warning even when the local label says Strong. A useful follow-up is to determine password strength the right way by layering local rules with a real blocklist screen, then switch to a manager-generated secret so the question of personal fact or dictionary exposure no longer applies to that account.
Beyond the Score: Managers, Blocklists, and Multi-Factor Authentication
A passing local label is one input, not the whole decision. The rest of the workflow is what actually protects the account.
- Use a password manager to generate and store a different random secret for every account. Reuse is the single largest driver of account takeover, because a leak on one site becomes a credential-stuffing attempt on every other site where the same string appears.
- Run the account provider's full blocklist or breach check on the complete proposed password before you commit it. The local meter cannot do this step for you.
- Enable multi-factor authentication on email, finance, cloud storage, and any administrator account. A long unique password plus a second factor is materially harder to compromise than either control alone.
- Prefer phishing-resistant passkeys where the service offers them. A passkey removes the password from the attack surface on that account entirely.
- Change a password when it is reused, exposed, or suspected compromised, rather than on a fixed calendar. Scheduled rotations of strong unique passwords add friction without reducing real risk.
When to Replace a Password Even If the Score Looks Fine
Some situations override the label, no matter how strong the local meter reports.
- The same string appears on another account or in a personal note.
- The service announced a breach that may include your account.
- You typed the value into a public computer, a screen-share, or a phishing clone of the real login page.
- The password contains a date, a pet's name, a street name, or any other fact that is public or easy to find.
- A teammate, family member, or former employer still knows the value.
In each of those cases the label from the local meter is descriptive, not protective. Generate a new unique secret in your manager, store it under the existing entry, and re-run the account provider's own breach check before you save.
Common Pitfalls When Interpreting a Strength Label
A short list of habits that quietly weaken the decision the label is supposed to support.
- Trusting a Strong label without checking the account provider's blocklist. Local patterns and remote leaks are different problems.
- Adding a single capital letter or symbol at the start or end of an otherwise weak string. The pattern check may not flag it, but attackers test those substitutions first.
- Reusing the same "strong" password across several accounts. One breach compromises all of them.
- Using a memorable quote, song lyric, or book passage that also appears in published text corpora. Length is not a substitute for unpredictability.
- Reading "No pattern detected" as "no weakness detected". The pattern rule is narrow on purpose, and the label does not cover dictionaries, leaked passwords, or personal facts.
For a deeper look, see Generate a SHA-1 Hash for a File Without Uploading It.