🔐 Password Strength Analyzer

Analyze password strength in real time — crack-time estimates and actionable improvement tips

Analysis runs in your browser. The breach check uses k-anonymity — only a 5-character hash prefix is sent, never your actual password.

{{ displayLabel }} Crack time：{{ displayCrackTime }}
Length：{{ result.length }}
Lowercase (a–z)
Uppercase (A–Z)
Digits (0–9)
Symbols (!@#…)
Entropy ≈ {{ result.effectiveEntropy.toFixed(1) }} bits

Issues Found

  • {{ item }}

Suggestions

  • {{ item }}

Strengths

  • {{ item }}

 Why Composition Checkers Lie, and What This One Does Instead

The classic "must contain an uppercase letter, a digit, and a symbol" checker rates P@ssw0rd1! as strong. Every password cracker disagrees: leet substitutions (@→a, 0→o) are the first rule in every cracking dictionary, so that password falls in milliseconds. Meaningful strength estimation has to model how attackers actually guess — the approach popularized by Dropbox's open-source zxcvbn estimator.

This analyzer follows the same philosophy in two passes:

  • Theoretical entropy — length × log₂(charset size). A 12-character password drawing on upper/lower/digits/symbols is ~78 bits.
  • Pattern penalties — the score drops for anything an attacker's rule engine tries early: top-common-passwords hits (checked after leet-decoding, so p@ssw0rd is caught), keyboard walks (qwerty, 1qaz2wsx), repeated runs (aaa, 111), probable years (19xx/20xx), digits-only or letters-only composition, and short length. What remains is the effective entropy that drives the level and crack-time display.

That's why a 16-character qwerty1234567890 still rates poorly here while a random 12-character string rates well — length only helps when the characters are actually unpredictable.

 The Breach Check: k-Anonymity in One Paragraph

Even a perfectly random password is burned the moment it appears in a public breach dump — credential-stuffing bots will try it within the first wave. So this tool checks your input against Have I Been Pwned's Pwned Passwords corpus of billions of real leaked passwords. The clever part is doing that without revealing your password to anyone:

  1. Your browser computes the password's SHA-1 hash locally.
  2. Only the first 5 hex characters of that hash are sent to the API. Each 5-character prefix matches roughly 800 different leaked hashes — that ambiguity is the "k" in k-anonymity.
  3. The API returns the whole candidate bucket, and the final comparison happens on your device. The server never learns which hash you were interested in, or whether it matched.

The response is also padded so network observers can't infer anything from its size. If the check reports a match, treat the password as public knowledge: rotate it everywhere it's used, and never re-derive variants of it (hunter2! after hunter2 buys you nothing).

 What "Crack Time" Actually Means

The estimate assumes an offline attack at 10 billion guesses per second — an attacker who stole a password database and is running GPU rigs against fast hashes. Real-world numbers swing by orders of magnitude in both directions:

  • Slower for the attacker: sites that hash with bcrypt, scrypt, or Argon2 cut guess rates by a factor of thousands compared to MD5/SHA-1. Online login forms with rate limiting are slower still — dozens of guesses per minute, not billions per second.
  • Faster for the attacker: if the password matches a dictionary rule or appears in a breach corpus, it falls in the first seconds regardless of its theoretical entropy — which is exactly what the pattern penalties and breach check model.
  • Irrelevant entirely: phishing, keyloggers, and session hijacking bypass password strength altogether. A strong password is necessary, not sufficient — enable two-factor authentication on your email and financial accounts, since your inbox is the reset key for everything else.

 Reading the Feedback: What to Fix First

  • Any "common password list" or breach hit → replace, don't repair. Appending a digit to a burned password doesn't help; crackers append digits too.
  • Under 12 characters → add length before anything else. Each extra random character multiplies the search space by the charset size; adding a symbol to a short password adds far less.
  • Keyboard walks and years → remove the pattern, not just pad around it. Pattern segments contribute almost no entropy, so qwerty!X9 is effectively a 3-character password.
  • Everything green but you had to memorize it? That's the tell you're managing passwords by hand. Move to a password manager and let it generate 16+ random characters per site — then the only password you memorize is the master passphrase (four to six truly random words works well).

 Frequently Asked Questions

Is it safe to type a real password into this page?

Strength analysis runs entirely in your browser — no request carries your password. The breach check transmits only a 5-character hash prefix under the k-anonymity scheme described above. If you'd rather not test a live password, test a structurally identical variant instead.

Why does the meter say "Compromised" even though the entropy looks high?

A breach-database match overrides everything else. Entropy measures how hard a password is to guess from scratch; a leaked password doesn't need guessing — it's already on the attacker's list.

Do non-ASCII characters (accents, CJK, emoji) make passwords stronger?

In theory yes — a larger character space raises entropy. In practice, some systems reject non-ASCII input, mobile keyboards make entry painful, and encoding mismatches between systems can lock you out. Length plus the full ASCII set remains the most portable strategy.

Should I rotate my passwords on a schedule?

No — NIST SP 800-63B dropped mandatory periodic rotation because it produces predictable increments. Rotate when there's a reason: a breach notification, a shared credential, or a device you no longer trust. Unique-per-site passwords plus 2FA beat any rotation calendar.

 Related Tools