Does this algorithm check breached passwords?

No. The Password Strength Checker makes no network query and clearly cannot know whether a value appears in a current breach corpus. Use the account provider's full blocklist check for that comparison.

Do I need uppercase, numbers, and symbols?

The algorithm reports character groups but does not require any specific composition. Length, uniqueness, blocklist screening, password managers, and MFA are more important than formulaic substitutions.

Can a Strong result still be weak?

Yes. A long quote, a reused secret, or a leaked passphrase may be guessed quickly. The label covers only documented local length and the two simple-pattern checks.

Why does the algorithm count Unicode code points instead of bytes?

Counting code points keeps emoji and other non-ASCII characters consistent across systems and makes length easier to reason about. A single emoji is one code point, not two UTF-16 halves.

Why is there no crack-time or bits-of-entropy estimate?

NIST notes that estimating entropy for user-chosen passwords is difficult, and the meter deliberately avoids advertising a guarantee it cannot back up. Treat the label as feedback, not certification.

Password Strength Algorithm: Rules Behind the Score

A password strength algorithm is the set of rules a checker applies to a proposed password to produce a score or label. The Password Strength Checker algorithm counts Unicode code points, reports how many broad character groups appear, flags simple repeated or sequential patterns, and assigns a five-level label from Weak to Strong. Because current NIST guidance treats passwords shorter than 15 characters as weak when the password is the only authentication factor, the algorithm prioritizes length and applies pattern caps rather than advertising a cracking-time or bits-of-entropy guarantee. Empty input scores zero, fewer than eight characters scores Weak, eight through fourteen scores Fair unless a simple repeated or sequential pattern is detected, and a non-patterned value of 15 through 19 characters scores Good while 20 or more scores Strong. These bands are feedback rules, not a claim that every long string is safe, and the meter makes no network call, stores nothing, and refuses to estimate entropy for user-chosen strings.

algorithm to check password strength — Password Strength Algorithm: Rules Behind the Score

What the Password Strength Algorithm Measures

A trustworthy password strength algorithm works from a small set of inputs that a user can audit. The Password Strength Checker takes exactly three observable inputs from the proposed password and produces a deterministic result that anyone can reproduce from the same string and the same rules.

Length in Unicode code points. Each character — including emoji, spaces, accents, and other non-ASCII code points — counts as one. The algorithm does not split supplementary characters or apply UTF-16 math, so an emoji such as 🎉 contributes a single code point rather than two surrogate halves.
Character-group presence. The algorithm reports how many broad groups appear: lowercase letters, uppercase letters, digits, symbols, whitespace, and non-ASCII characters. Group count is descriptive only; the algorithm never requires a specific group to be present.
Pattern matches. Two narrow, explainable checks fire when the algorithm finds a short chunk of up to four code points repeated at least three times, or a run of four code points increasing or decreasing by one.

From those three inputs the algorithm derives a five-level label. There is no entropy estimate, no crack-time headline, and no remote query, and that is exactly the point: the result is auditable rather than theatrical.

How the Five-Level Score Is Calculated

The scoring rules are deliberately boring so they can be reasoned about. Length is the dominant factor because NIST SP 800-63B treats short passwords as weak when they are the sole authentication factor, and a simple pattern cap keeps known foot-guns from earning an inflated label.

Label	Condition
Empty	No characters entered (score 0)
Weak	Fewer than 8 characters
Fair	8 to 14 characters, or any length that triggers a simple repeated or sequential pattern
Good	15 to 19 characters, non-patterned
Strong	20 or more characters, non-patterned

The pattern cap matters: a 30-character string made of abcabcabcabc still scores Fair because the repeated-chunk rule fires first. Likewise 1234abcd is capped because the algorithm detects a four-character monotonic run. Eight fixture passwords lock these boundaries in tests so the published labels cannot drift: empty, short, sequential, repeated, a 14-character value, an 11-character mixed value, a 19-character phrase, and a 28-character passphrase.

The algorithm does not require one of each character group, and it does not award bonus points for forced composition. Forcing uppercase, digits, and symbols often pushes users toward predictable substitutions such as P@ssw0rd1, which is exactly the kind of predictable substitution that forced composition rules tend to encourage. Spaces and Unicode are allowed so a memorable passphrase can be evaluated on its own terms, as long as the target service accepts and normalizes those characters consistently.

Pattern Detection: What the Rules Catch

Pattern detection is intentionally narrow so the algorithm can explain every finding. The repeated-chunk rule looks for a substring of one to four code points that appears at least three times in a row or scattered through the input. The sequential rule looks for four code points in a strictly ascending or descending run, such as abcd, 4321, or wxyz. When either rule fires, the algorithm caps the score at Fair regardless of length.

What the algorithm does not catch is just as important to document. It does not recognize:

Keyboard walks longer than four code points, such as 1qaz2wsx across columns.
Dictionary words, names, dates, song lyrics, or quotes that simply happen to be long.
Leaked passwords or values that appear in a public breach corpus.
Service-specific words or personal facts that an attacker might guess from social context.

A clean "No pattern" flag only means those two narrow checks did not fire. The algorithm is honest about that boundary: a Strong label covers documented local length and simple-pattern checks, and nothing else.

Run the Algorithm on a Password in Three Steps

Open the Password Strength Checker and type or paste the proposed password into the input field. The value stays hidden by default and nothing leaves your browser; press Show only if you need to see what you typed.
Review the four outputs the algorithm exposes: the Unicode code-point length, the descriptive count of character groups, the pattern flag (repeated, sequential, or no pattern), and each recommendation. Each recommendation next to the score names the rule that fired.
Compare the result with the three things the algorithm does not check: a current breach or blocklist, a uniqueness check against your other passwords, and a multi-factor authentication option. Use a password manager to generate and store a different value for each account, and prefer a phishing-resistant passkey when the service offers one. If you want a deeper methodology read alongside this algorithm walkthrough, the guide on determining password strength the right way covers the supporting decisions.

What the Algorithm Cannot Detect

Estimating entropy for a user-chosen password is genuinely difficult, which is why NIST SP 800-63B advises against claiming bits-of-entropy numbers for human input. The Password Strength Checker deliberately refuses that claim. Attackers do not try every combination; they use breach corpuses, dictionaries, service-specific wordlists, keyboard paths, personal facts, and probabilistic models, none of which a length-only meter can model locally.

The algorithm also cannot verify that the password is unique to this account. A 28-character passphrase that you reused across three services is still a single point of failure, and the meter has no way to know. The OWASP Authentication Cheat Sheet recommends salted password-hashing functions such as Argon2id, bcrypt, or scrypt on the server side, which is why a server blocklist of common, expected, and compromised values is the correct place to catch leaked secrets. Treat the local score as guidance for picking a better secret, not as certification.

Beyond the Score: Password Manager, Blocklist, MFA

An algorithm is one input to a complete password decision. The remaining inputs are operational, and they matter more than the label itself.

Use a password manager. Generate a different random password for every account, store it in the manager, and let it fill in the field. Uniqueness is what neutralizes cross-site breach reuse, and length falls out of the manager for free.
Check the service's blocklist. The local meter does not query a breach corpus. Let the account provider do that comparison at signup or password change, and trust its warning even when your local meter says Strong.
Enable multi-factor authentication. Add a second factor for email, finance, cloud, and administrator access at a minimum. A phishing-resistant passkey is preferable where supported, because it removes the password from the attack surface entirely.
Rotate on evidence, not on the calendar. Change a password only when it is reused, exposed, or suspected compromised. Forced periodic rotation tends to produce predictable variants such as Spring2026! followed by Summer2026!, which the algorithm would happily label Fair while doing nothing for actual security.

Run the algorithm, read the four outputs literally, and then layer the operational controls. That combination — transparent local rules plus a manager, a service blocklist, and a second factor — is what closes the gap between a label and a real defense.

If you're weighing options, Free 16-Character Password Generator That Runs Locally covers this in detail.