Treating composition as strength
Adding one capital letter, digit, and symbol to a common word often remains predictable. NIST advises verifiers not to impose composition rules; use a long, unique value and a blocked-password check instead.
Password Strength Checker | Local Pattern-Based Estimate
SecurityRuns in Your Browser (No Uploads)
Estimate how guessable a password is with a locally loaded zxcvbn-ts model that recognizes common passwords, dictionary terms, dates, repeats, sequences, and keyboard patterns. The browser loads the model only when requested, caps input at 256 Unicode code points, and returns only score, guess-order, pattern categories, and review guidance rather than the raw password or matched tokens. The estimate does not query a breach corpus, model every language or personal fact, predict a universal crack time, or prove that an account is secure; verifier hashing, rate limits, reuse, recovery, phishing, MFA, and device compromise remain separate controls.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Use repeating-key XOR for learning, not security
This workflow uses the Cipher Learning Workbench to make XOR byte mechanics visible. You will reproduce a known vector, switch between Hex and Base64, reverse it with the same key, and document why the exercise must never be presented as protection for real secrets.
OpenRelated toolCipher Learning Workbench | Compare Six Historical Methods
Compare six bounded classical and toy cipher methods locally with strict keys, exact outputs, and clear security limits.
OpenRelated toolHash Generator and File Checksum | SHA-256 and MD5
Hash UTF-8 text or exact file bytes and compare a full checksum locally.
OpenRelated toolRandom Data Workbench | Numbers and Test Strings
Generate unbiased numbers and configurable unique strings for test data, with exact line, CSV, and JSON export.
OpenHow to Use This Tool
Prefer checking a newly generated candidate before it becomes an account credential. For an existing critical password, use the audit built into a trusted password manager rather than exposing it to another page.
Enter or paste the complete value without trimming it. The field starts masked, accepts spaces and Unicode, and rejects more than 256 Unicode code points instead of silently truncating.
Run the analysis. The zxcvbn-ts dictionaries and pattern matchers load locally only after the command, so the initial page does not carry the full estimator bundle.
Read the 0-to-4 score and guess scale as model estimates. Review common-word, keyboard, repeat, sequence, and date findings instead of chasing uppercase, digit, or symbol checkboxes.
Compare the Unicode length with the NIST verifier checkpoints: 15 for a single-factor password and 8 only when the password is used within MFA. A length checkpoint alone is not approval.
Replace weak candidates rather than making predictable edits. Store a different manager-generated value for each account, verify the destination accepts it in full, and enable MFA or a passkey where available.
When to Use This Tool
New account credential review
Reject a predictable candidate before creating an account, then save a unique manager-generated replacement before submitting it to the service.
Security awareness training
Demonstrate why Password1-style substitutions, keyboard walks, repeated chunks, dates, and famous phrases remain guessable despite satisfying old composition rules.
Verifier UX prototyping
Check whether a proposed registration flow provides meaningful pattern feedback while separately enforcing length, blocklist, rate-limit, storage, paste, and MFA requirements on the server.
Passphrase design review
Compare a memorable candidate with a newly generated random value without publishing either result or interpreting the model as a breach check.
Synthetic support diagnostics
Reproduce a support report involving an obviously synthetic test value. Never copy a customer's real credential into a ticket, test case, screenshot, or this page.
Common Mistakes
Reading the score as a guarantee
A 4/4 result is only this model's estimate. It cannot see reuse on another service, a future breach, a keylogger, phishing, weak server-side hashing, recovery weaknesses, or a personal fact absent from its dictionaries.
Assuming a breach check occurred
This checker intentionally makes no network request to a breach corpus. A low score is actionable, but a high score does not mean the value has never appeared in a leak.
Ignoring uniqueness
A password reused across accounts enables credential stuffing even when it is long. Replace reuse with a different manager-stored value for every account.
Overstating local privacy
Local application processing does not control browser extensions, screen capture, device malware, clipboard history, or someone watching the display. Prefer testing a new candidate before use and use a trusted password manager's built-in audit for existing critical credentials.
Examples
Common password with composition
The checker should flag a decorated common password instead of rewarding its uppercase letter, digits, and symbol. Do not use the example as a credential.
Input
Password1234!Output
Low model score; common-password or dictionary pattern; replace rather than decorateNew random credential workflow
A manager-generated value should be evaluated before account creation, stored before submission, and used on only that account. The actual value is intentionally not published here.
Input
A new 20+ character password generated by a trusted password managerOutput
Review the pattern estimate and service compatibility; uniqueness and MFA remain separate checksCandidate passphrase review
A multi-word passphrase can benefit from length, but famous quotations, predictable word sequences, names, and personal facts may still be guessable or missed by the model.
Input
A new service-specific passphrase not copied from a quotation or personal profileOutput
Check detected patterns, then store it uniquely and enable MFA or a passkeyHow the local guessability estimate works
The analyzer uses @zxcvbn-ts/core with the common-password, English dictionary, and keyboard-graph packages. The estimator searches for dictionary, l33t, spatial, repeat, sequence, word-sequence, date, regex, and brute-force segments, then chooses a low-guess explanation for the full input.
The libraries are imported only when analysis starts. No remote scoring API or breach endpoint is called. If the local chunks cannot load, the tool returns an error rather than substituting the old character-class formula.
The raw estimator response contains the password and matched tokens, so the adapter immediately projects it into a restricted result containing only score, code-point length, guess-order magnitude, pattern categories, NIST length booleans, recommendations, and calculation time. UI state and analytics never receive the raw response.
Length is counted with Unicode code points rather than JavaScript UTF-16 code units, matching NIST's verifier guidance. The hard limit is 256 code points; over-limit input is rejected visibly and never silently shortened for analysis.
The guess scale is floor(log10(estimated guesses)). Exact crack-time labels are deliberately omitted because attacker hardware, hash cost, leaked verifier data, online rate limits, and guessing strategy make a universal time claim misleading.
NIST SP 800-63B-4 says verifiers should block common or compromised passwords, allow password managers and paste, avoid arbitrary periodic changes and composition rules, require 15 characters for single-factor use, allow 8 within MFA, and permit at least 64. A client-side estimator supports feedback but cannot implement verifier-side storage, blocklists, throttling, recovery, MFA, or phishing resistance.
Frequently Asked Questions
Is the password uploaded or recorded?
The checker dynamically loads zxcvbn-ts in your browser and analyzes the value in memory. The returned result and tool analytics contain only aggregate fields such as score, Unicode length, pattern count, and calculation time, not the password or matched token. The value is still present in the page and may be visible to browser extensions, device malware, screen capture, or anyone who reveals it.
Does 4 out of 4 mean the password is secure?
No. The 0-to-4 score is a pattern-based guessability estimate, not proof that an account is safe. It does not model every attacker, verifier hash, rate limit, phishing path, recovery process, reused credential, or personal fact.
Does this check breached-password databases?
No breach service is contacted. The bundled dictionaries catch many common passwords and patterns, but cannot establish whether the exact value appears in a current breach corpus. Use the destination service or a reputable password manager's breach-monitoring feature for that separate question.
How should I interpret the 8- and 15-character checks?
NIST SP 800-63B-4 requires at least 15 characters for a single-factor password, permits a minimum of 8 when the password is used only as part of MFA, and says verifiers should permit at least 64. Those are verifier requirements, not a promise that any 15-character value is strong.
Does the model understand every language and personal word?
The main dictionaries are common-password and English-language sets plus keyboard graphs. Korean, Japanese, niche jargon, service-specific terms, and personal information can be underrepresented, so the model may overestimate a phrase it does not recognize. Treat the result conservatively.
What does the guess scale mean?
It is the floor of log10 of the model's estimated guesses, displayed as 10^n. It communicates rough scale without claiming an exact cracking time. Hardware, guessing strategy, password hashing, leaks, and rate limits can change real attack cost substantially.
When should I use this checker?
Prefer a trusted password manager's generator and audit for real accounts. This checker is useful for education, reviewing a new candidate before use, testing a verifier policy, or showing why a familiar pattern is weak. Never reuse the tested value, and add MFA or a passkey where available.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: Using Password Strength Checker, we reproduced “Reject a decorated common-password test value” from the exact sample input. The result comparison covered “Use a new or synthetic candidate” and “Prepare a controlled browser session”; the linked test evidence was then checked for “Treating 4 out of 4 as approval” and “Fixing a weak result with predictable decoration”.
Expected result: The decorated common-word candidate was rejected for predictable pattern and length evidence, and neither the candidate text nor an unsupported “safe” verdict was stored.
Sources and standards
- NIST SP 800-63B-4: Authentication and Authenticator ManagementNational Institute of Standards and Technology
Related workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Use repeating-key XOR for learning, not security
This workflow uses the Cipher Learning Workbench to make XOR byte mechanics visible. You will reproduce a known vector, switch between Hex and Base64, reverse it with the same key, and document why the exercise must never be presented as protection for real secrets.
Workflow guideReview a password candidate without false assurance
A password meter can reject obvious patterns, but it cannot certify an account. This workflow limits testing to new or synthetic candidates, prepares a trusted browser environment, checks the complete value without silent trimming, interprets zxcvbn scores and guess orders as rough model output, treats NIST length checkpoints as verifier requirements, performs breach monitoring and service controls separately, and records only non-secret decisions. The outcome is either reject and regenerate, accept provisionally for one account, or escalate to the destination's security policy without ever placing the tested value in a ticket, screenshot, analytics field, or shared note.
Workflow guideCreate and store a unique password without plaintext leftovers
A random generator solves only the value-selection step. A reliable password workflow begins with the real service contract, uses a trusted device and a unique long value, saves the result in a password manager before submission, verifies that the destination accepted the complete value, enables phishing-resistant authentication where possible, records recovery material separately, removes clipboard and downloaded plaintext, and retains enough evidence to recover or revoke access without reusing the secret.
Related Tools
Continue with another maintained workflow
Cipher Learning Workbench | Compare Six Historical Methods
Compare six bounded classical and toy cipher methods locally with strict keys, exact outputs, and clear security limits.
Encoding
Hash Generator and File Checksum | SHA-256 and MD5
Hash UTF-8 text or exact file bytes and compare a full checksum locally.
Encoding
Random Data Workbench | Numbers and Test Strings
Generate unbiased numbers and configurable unique strings for test data, with exact line, CSV, and JSON export.
Converter
Random Password Generator | Web Crypto, No Weak Fallback
Generate one 8-128 character password locally with Web Crypto, unbiased sampling, masking, and explicit character sets.
Security
Security Headers Checker | Final HTTP Response Review
Review the final pasted HTTP response for enforced and context-dependent security-header signals.
Security