Generators

Password Checker

Check password strength using Google-style rules and get security advice.

Check Password
🔍
Enter password to start checking
Check if your password meets Google password rules and security standards

What is Password Strength Checker?

Password strength checker analyzes passwords and evaluates their security level based on various criteria.

Evaluation Criteria

  • Length (minimum 8, recommended 12+)
  • Character variety (upper, lower, numbers, symbols)
  • Common pattern detection
  • Dictionary word checking

Strength Levels

  • Weak: Easy to crack
  • Medium: Moderate security
  • Strong: Good security
  • Very Strong: Excellent security

Scores a password against Google-style composition rules. Nine fixed checks cover length, lowercase, uppercase, digits, symbol presence, 20 common-password strings, three-in-a-row repeats, three-character sequences, and keyboard runs, plus conditional username and email checks. It reports a percentage and one of four labels. Read it to find which rule a credential breaks, not to estimate crack time.

What the percentage actually counts

The bar is a pass ratio, not an entropy estimate. Nine checks always run: length, lowercase, uppercase, digit, symbol presence, the 20-entry common-password list, three-in-a-row repeats, three-character sequences, and five keyboard substrings. Two more rows are appended only when the username and email boxes are filled, so the denominator moves between 9 and 11 and the same password can print 89% or 90%. The symbol row is recorded as passed even when no symbol exists: a missing symbol only ever produces a suggestion, never a deduction. Brackets are below 50% weak, below 70% fair, below 85% strong, else very strong, and any length under 8 forces the "too short" label before the ratio is consulted.

The pattern rules are literal substrings

Common-password detection lowercases the input and tests whether it contains one of 20 fixed strings, so Sunshine#2024 hits sunshine and badminton9Xz! hits admin; capital letters, punctuation and trailing years hide nothing. Sequence detection covers only the forward digit triples 012 to 789 and the forward letter triples abc to xyz, matched case-insensitively, so 987, cba and ace pass untouched. Repeat detection is the regex (.)\1{2,}, which needs three identical characters in a row: aa11bb passes, aaa fails. Keyboard coverage is five strings — qwerty, asdf, zxcv, qaz, wsx. The email row compares only the part before @.

Why "very strong" is not a security verdict

Because the score rewards satisfying a checklist, the random 10-character string Xk7!mQr2#z and the 15-character Correct-Horse-9 both return 100%. There is no attacker model, no dictionary attack simulation, no breach-list lookup, and no measurement of the guess space implied by the length. NIST SP 800-63B pushed guidance toward length plus screening against known-compromised passwords for exactly this reason: character-class counting overstates short strings and punishes long passphrases. Read the result as the answer to "does this satisfy Google-style composition rules", then read the individual failed rows — a hit on a listed word or an embedded username outweighs two percentage points.

Worked example

Scoring a password that contains a listed word

Input 
Sunshine#2024
Output 
8 of 9 checks passed · 89% · Very strong · failed: "Password contains common password patterns" · badge: "Does not fully meet Google password requirements"

The word sunshine is one of the 20 stored strings and matching is a lowercase substring test, so the capital S, the # and the year change nothing. Eight of nine checks pass, which puts 89% inside the very-strong bracket, yet the badge stays on the not-met variant because the common-word rule belongs to the Google requirement set. Typing any unrelated username adds a tenth, passing row and moves the display to 90%.

Limits and pitfalls

  • The common-password list holds 20 strings and matching is substring-based, so leaked classics that avoid the list (Passw0rd!, Dr4g0nfly!) score 100%, while innocent words containing admin or monkey are flagged.
  • The username and email rows exist only while those boxes are non-empty; leave them blank and the similar-to-identifier check is skipped entirely, so a password built from your own name can show every row green.
  • A missing symbol is stored as a passed check with a suggestion attached, so a password containing no punctuation at all can still display 100%.
  • Length is counted in UTF-16 code units, so each emoji counts twice: six emoji reach the "12 characters" row while only six of nine checks pass (67%, Fair).
  • Nothing leaves the browser, but there is also no breach lookup — structural checks cannot tell you that a password already sits in a leaked corpus.

Related tools

When it goes wrong

The field stays dots and there is no eye icon anywhere, so fixing one mistyped character means retyping the whole password blind.

CauseThe input is hardcoded to type="password" in the template and no toggle is rendered beside it. The string tools.pwdcheck.showPassword exists in the locale files, but no element binds to it; the only button in the wrapper is the clipboard one.

FixClick the clipboard button next to the field, paste the value into any plain text input to read it back, edit there and paste the corrected string in. Keep the username and email boxes filled while you retry, since clearing the password row by row is the only other feedback you get.

The badge is green, "Meets Google password requirements", yet a row right below it is red for repeating characters.

CauseThe badge is not derived from the row list. meetsGoogleRequirements re-tests a separate and shorter set: length of 8 or more, one [a-z], one [A-Z], one [0-9], no match against the 20 common strings, and no username or email local part inside the password. Symbol presence, triple repeats, three-character sequences and keyboard runs are never consulted.

FixRead the rows first and the badge second. Aa1!bbbX is the smallest case that reproduces it: 8 of 9 rows pass, the bar reads 89% and "Very strong", the badge is green, and the repeat row is red on bbb. Break those three identical characters and the red row goes away on its own.

A Chinese passphrase typed in full gets called "Too short" at 56%, with length, lowercase, uppercase and digit all marked red.

CauseLength is pwd.length, UTF-16 code units, so seven Hanzi count as 7 and miss the 8-character row. The class rows use ASCII-only patterns /[a-z]/, /[A-Z]/ and /[0-9]/, which Hanzi never match, while the symbol row passes because /[^a-zA-Z0-9]/ accepts every non-ASCII character as special.

FixUse the page as an ASCII composition checker and judge a Hanzi passphrase by its own length, plus a leak lookup for whether it is public. Splicing ASCII in front, as in 密码安全Ab1!好, does turn all nine rows green and print 100%, but that is the four class rows being satisfied, not the passphrase becoming stronger.

A password generated elsewhere is flagged for containing the username, even though it was never built from the name: username Dan, password Dancing9!Qq.

CauseBoth sides are lowercased and compared with includes, with no word boundary and no minimum username length, so dancing trips a three-letter name. The row only exists while the username box is non-empty, which is why the same string passes with the box blank.

FixClear the username box to skip that row, or choose a string whose letters never run your name, such as Qm7!Rt2p. Keep the box filled for credentials that matter: with Dan entered, Dancing9!Qq reads 9 of 10 rows, 90%, and the badge drops to the yellow variant even though the label still says "Very strong".

A nine-row checklist versus the tools that answer the other questions

DecisionThis password checkerAlternative
You have to show which named rule a password breaksThat is the whole design: nine rows always run, each with its own message, so the red line spells out the rule instead of returning a single number.zxcvbn gives one score plus the pattern it matched; better at ranking, worse when the requirement is a per-rule line a user can read back.
You need a figure that orders passwords by guessing costNo attacker model: the bar is passed rows over total rows, so the 8-character Qm7!Rt2p and a 16-character random string both read 100%.zxcvbn: it decomposes the string into dictionary, keyboard, date and l33t matches and returns a guesses estimate, which is the one thing this page cannot produce.
The password may already be in a leaked corpusNot possible offline. The only wordlist is the 20 strings compiled into the component, compared as lowercase substrings, so an unlisted leaked password scores 100%.Pwned Passwords range API: send the first five hex characters of the SHA-1 and read the count for your suffix back, so the full hash never leaves the machine; or import the dump and test locally.
You want a password to keep, not a verdict on one you haveNothing is generated here. A red row says the string has to change, but the replacement has to come from somewhere else.Password generator on this site: choose length and character set and copy the result; on a server, openssl rand -base64 18 turns 18 random bytes into 24 characters.
The password is about to be storedOnly string comparison happens: no hash, no salt, no cost parameter, so the percentage has nothing to do with how the credential is kept.PBKDF2 tool for a derived key in the browser, or Argon2id and bcrypt on the server. What goes into the database is the hash, never a strength score.
The same check has to run inside a sign-up formA page tool: paste, read the rows, act. Nothing is exported, so putting this into a form means copying the rules out by hand.Add zxcvbn as a dependency and call it on input, or lift these rules as regexes: length 8, [a-z], [A-Z], [0-9], [^a-zA-Z0-9], 20 substrings, (.)\1{2,} and the five keyboard strings.

Frequently Asked Questions

Is the analysis local? Is my password uploaded?
Strength scoring runs entirely in your browser; nothing is sent anywhere. The checker applies heuristics — length, character variety, common patterns (keyboard walks, repeats, dictionary words) — measuring structural resistance to cracking.
Does a "strong" rating guarantee safety?
Structural strength is necessary but not sufficient: a patternically strong password that appeared in a breach database is still dangerous. Combine with breach lookups (like haveibeenpwned) and unique passwords per site.
Why does "Password1234@Ab" score low?
Crackers try dictionaries far earlier than brute force: common words, common substitutions (a→@, s→$), trailing digits are round one. Pattern recognition downgrades these structures — which is exactly the value over older checkers that only counted length and character classes.

Content reviewed: