Password Strength Checker
Entropy, charset coverage and time-to-crack across realistic attacker hardware budgets. Your password is evaluated client-side; nothing is sent to a server, logged, or kept in localStorage.
FAQ
Does this tool transmit my password?
No. Strength evaluation runs synchronously inside your browser as you type. There is no fetch() or XHR call, no analytics on the input field, no third-party script that has access to the value. You can verify by opening the DevTools Network tab — typing in the password field generates zero network traffic.
How is entropy calculated?
Raw entropy follows the Shannon definition: bits = length * log2(charsetSize). The charset is the union of pools detected in the password — 26 for lowercase, 26 for uppercase, 10 for digits, 33 for ASCII symbols, plus 1000 for any UTF-8 character outside ASCII (a deliberately conservative under-estimate of the actual Unicode space). Effective entropy then applies pattern penalties: common-password dictionary hit, 4+ character ascending/descending/repeating sequences, single-class compositions and short length.
Why are the time-to-crack estimates so wide?
Because attacker capability spans roughly 11 orders of magnitude. A web login limited to 10 attempts/second is the floor; a 100-GPU cluster brute-forcing fast hashes like SHA-1 or NTLM is the ceiling. The slow-hash row reflects bcrypt or Argon2id with realistic cost factors, which is what well-designed authentication systems use. If your password is stored as bcrypt it can be much weaker than if it is stored as raw SHA-1 — that's why the column matters more than the absolute bit count.
Is this the same algorithm zxcvbn uses?
It is in the same family — entropy with pattern penalties — but it is not byte-compatible with Dropbox's zxcvbn. Real zxcvbn ships large pattern dictionaries (~30k words, common name lists, leet-speak substitutions) that would bloat the page bundle. We use a much smaller curated common-password set and a handful of sequence/repeat heuristics. For high-stakes scoring, run zxcvbn or zxcvbn-ts locally and feed your own dictionaries.
What is a reasonable target entropy in 2025?
NIST SP 800-63B requires user-chosen secrets to be checked against a breach corpus and bans dictionary words and repeats — there is no fixed bit requirement. Industry rule of thumb: 60+ bits of effective entropy for human-typed passwords, 128+ bits for machine-generated secrets (API tokens, signing keys, recovery codes). Anything above 80 bits resists offline GPU attacks on fast hashes for centuries.