A password's strength comes down to three measurable properties: its length in code points, whether it repeats or sequences obvious patterns, and whether the service you're using blocks it outright. Current NIST guidance treats passwords shorter than fifteen characters as weak when the password is the sole authentication factor, because attackers don't enumerate every character — they run breach corpuses, dictionaries, keyboard walks, service-specific words, and probabilistic models against the input. Strength is less about the abstract variety of characters and more about whether the secret you picked stands out from the predictable mass of leaked and common values. A local, transparent meter can review those three properties without uploading the password or estimating a misleading crack time, which is exactly what a tool like the Password Strength Checker is built to do: count code points, flag simple repeats and monotonic sequences, and report a five-level label you can act on.
What Actually Determines Password Strength
Password strength is not a single number — it is a small bundle of properties that together describe how hard the secret is to guess in practice. Once you name the properties, the order in which you should weight them becomes obvious.
Length is the dominant factor. Per NIST SP 800-63B, a user-chosen password used as the only authentication factor should be at least fifteen characters long; shorter values are treated as weak because they fall inside the practical reach of modern dictionary and breach attacks. Each additional code point multiplies the candidates an attacker must consider, and length scales faster than any composition rule you could enforce.
Uniqueness matters as much as length. The single biggest driver of account takeover is reuse across services: one breach exposes every account that shared the same secret. A long, unique password that has never appeared in a leak is harder to attack than a shorter one that already lives in a publicly traded breach corpus.
Predictability is the third axis. Repeating chunks such as abcabcabc or monotonic runs like abcd collapse the effective search space to something an attacker can enumerate in seconds. Recognizing those narrow patterns is cheap and unambiguous; recognizing every keyboard walk, quote, lyric, name, or leaked value is not, which is why real-world verifiers have to combine a meter, a breach feed, and a password manager.
The Limits of Most Online Strength Meters
Browser-based meters have improved over the years, but the common ones still make three promises they cannot actually keep.
Many advertise a "crack time" or a "bits of entropy" figure as if it were a physical measurement. NIST itself notes that estimating entropy for user-chosen passwords is difficult, because the underlying distribution is shaped by human behavior, not uniform randomness. A single number with three significant digits is theatre, not analysis.
Most meters also enforce composition — uppercase, lowercase, digit, symbol — and grade you down if a category is missing. Forced composition rules have been shown to push users toward predictable substitutions like P@ssw0rd1! and do not replace length or blocklist screening. Variety is information, not a rule.
Finally, many meters upload the password to a remote server to "check" it. Even if the operator logs nothing, that transmission crosses trust boundaries and adds an attack surface. A truly transparent meter keeps the value in the page and shows you the rules it applied, so you can audit the output yourself.
Local, Transparent Evaluation Step by Step
The fastest way to know whether a candidate password is reasonable is to run it through a local meter whose rules are documented. The Password Strength Checker is built around that idea: nothing leaves the browser, the rules are explicit, and the output is descriptive rather than predictive.
- Type or paste the proposed password into the input. The field stays masked by default, so shoulder-surfing risk is reduced. Press Show only when you are alone and need to verify a specific character.
- Read the length in code points. Because the meter counts Unicode code points, an emoji counts as one character, not two UTF-16 units, and a passphrase with spaces or non-ASCII letters is measured the same way the target service should measure it.
- Review the descriptive character-group count. The meter notes lowercase, uppercase, digits, symbols, whitespace, and non-ASCII characters separately, but does not require one of each — the count is information for you, not a rule the meter enforces.
- Look at the pattern flag. The checker reports whether it found a short chunk of one to four code points repeated at least three times, or a run of four code points increasing or decreasing by one. A clean result means those two narrow checks did not fire, not that the password is unguessable.
- Read the five-level label and each recommendation. Use the score as feedback for choosing a better secret, then verify the actual service accepts the characters, and rely on the account provider's blocklist, your password manager, and MFA for the rest.
Reading the Score: Thresholds and What They Mean
The five-level label is built from explicit feedback rules, not from an entropy estimate. Knowing the boundaries helps you decide what to change before you submit the secret anywhere.
| Label | Trigger condition |
|---|---|
| Empty | No code points entered. |
| Weak | Fewer than eight code points. |
| Fair | Eight through fourteen code points, or any length that triggers the repeat or monotonic-sequence pattern check. |
| Good | Fifteen through nineteen code points with no detected pattern. |
| Strong | Twenty or more code points with no detected pattern. |
Two boundaries deserve attention. First, a password that trips the repeat or sequence check is capped at Fair regardless of length, which is a deliberate signal that the secret contains structure an attacker can exploit. Second, the thresholds below fifteen characters are stricter than the labels above them, because NIST treats sub-fifteen-character user-chosen passwords as weak when they are the only factor. The score is a published rule, not a claim about how fast the password could actually be cracked.
Beyond the Meter: Blocklists, Managers, and MFA
A local meter cannot do everything, and the gaps it leaves are the ones most likely to bite you in production.
The meter does not query a breach corpus. It has no way to know whether the exact string has appeared in a leaked dump, so it cannot tell you that a fifteen-character passphrase of a famous quote is, in practice, a dictionary entry. For that, the account provider's full blocklist check is the right tool — follow its warning even if the local meter reports Strong, because the blocklist sees what the meter cannot.
Composition rules are descriptive, not required. The meter reports the character groups present and stops there; you do not need an uppercase letter, a digit, and a symbol in every password. Length, uniqueness, and blocklist screening outweigh forced variety, and generating a fresh random secret per service removes the trade-off entirely. Pairing the meter with a local Password Generator and a password manager is the standard workflow: generate once, store once, never reuse.
Multi-factor authentication finishes the picture. A long, unique, blocklist-passing password still benefits from a second factor on email, finance, cloud, and administrator accounts, and from a phishing-resistant passkey wherever the service supports it. Strength is layered: the meter covers length and obvious patterns, the blocklist covers known leaks, the manager covers storage and uniqueness, and MFA covers the case where one of the other layers fails.
When a Strong Label Still Hides a Weak Secret
Three common scenarios produce a Strong result and still leave the account exposed, and recognizing them in advance saves you from rotating the wrong password.
A long quote, lyric, or famous line. The meter only catches narrow repeats and monotonic sequences. A perfectly well-formed English sentence scores Strong on length and pattern, and may still be one of the first entries an attacker tries because it appears in song lyrics, books, and social-media bios. The OWASP Authentication Cheat Sheet explicitly warns that passphrases built from common phrases fall to dictionary-style attacks.
A reused secret from another site. The meter has no record of your other accounts, so a reused twenty-eight-character passphrase scores Strong even though a single breach on any of the other services compromises it everywhere you used it. Treat reuse, exposure, and suspected compromise as triggers to rotate immediately, not as issues to schedule on an arbitrary calendar.
A value that is in a breach corpus the meter has not seen. The page makes no network query and does not download a breach database, so it cannot tell you that the password has appeared in a leak. Follow the account provider's breach warning, change the password, and revoke active sessions or tokens for that account.
The honest framing is that a Strong label is the end of one check, not the end of the process. Combine the meter with a password manager, the service's blocklist, MFA, and a healthy suspicion of long memorable phrases, and the secret you actually use will be much closer to genuinely strong than the score alone suggests.