Password Strength Checker
Real-time analysis with the zxcvbn engine: common-password dictionaries, keyboard walks, sequences, repeats and dates all cost you points — a far truer measure of security than counting upper/lower/digit/symbol classes. Everything runs locally; your password never leaves the browser.
- Engine
- zxcvbn
- Score
- 0–4 scale
- Privacy
- Never uploaded
- Dictionary
- Common passwords built in
Advanced policy settings
Comma- or newline-separated, case-insensitive. zxcvbn automatically catches case variations, leet substitutions (e.g. Pa$$w0rd) and reversals.
Compare two passwords
WHY IT MATTERS
Why "upper + lower + digit + symbol" isn't security
P@ssw0rd! ticks all four character boxes and still tops real breach lists. Strength is about guessability, not character-class arithmetic.
Weak-password matching
A built-in dictionary of common passwords and words is penalized heavily — password, 123456 and P@ssw0rd correctly score as very weak.
Pattern detection
Keyboard walks, straight sequences, repeats, dates and common words all shrink the effective guess space.
Effective, not theoretical entropy
The score estimates real guesses from the structures found — not charset size multiplied by length.
Two attack scenarios
Separate estimates for offline GPU cracking and online rate-limited guessing build intuition about attacker cost.
Custom policy & blocklist
Set minimum length and class requirements; add company names or project codenames to match corporate password rules.
Fully local
Your password never leaves the browser or touches a server; settings live only in your own localStorage.
Understanding password strength
How the scoring works, what crack times mean, and what actually makes a good password.
How is zxcvbn's 0–4 score calculated?
zxcvbn first splits the password into chunks: dictionary words (common passwords, English words), keyboard walks, sequences, repeats, dates and brute-force fragments.
It estimates guesses per chunk, combines them into a total guess count, and maps it to a 0–4 score. Common transformations are accounted for automatically — capitalization reversal, leet substitutions (@→a, 0→o), year suffixes — which is why P@ssw0rd scores poorly despite its character variety.
What's the difference between effective entropy and charset size?
Charset size multiplies alphabet size by length — a theoretical ceiling that assumes every character is fully random, which real passwords virtually never are.
Effective entropy (the bit count shown here) is the real guess space zxcvbn estimates after finding dictionary words and patterns. At the same length, iloveyou2024 has far less effective entropy than a random string.
How are crack times estimated — are they reliable?
Crack time = estimated guesses ÷ guesses per second. Two speeds are shown: ~10 billion/sec for an offline GPU farm (attacker has the hash), and ~100/hour for an online rate-limited login.
Treat them as orders of magnitude, not predictions: real speed depends on the hash algorithm (bcrypt/Argon2 are orders of magnitude slower than MD5), hardware and dictionary quality. Being off by 10× changes nothing; a million-fold gap does.
What actually makes a good password?
Two solid routes: a random 16+ character string from a password manager, unique per site; or a passphrase of 4+ unrelated words (like correct-horse-battery-staple) — long and meaningless.
Whichever you choose, pair it with multi-factor authentication (MFA) and never reuse the same password across sites.
My site requires upper/lower/digit/symbol — why the low score?
Corporate policy (length, character classes) is a compliance floor: it answers "does it conform?". The zxcvbn score answers "can it be guessed?". The two are independent.
Adding an exclamation mark and a year to a common word (password!2024) passes most policy checks but falls to a dictionary attack in seconds.
Is my password uploaded anywhere?
No. Everything runs in your browser via JavaScript — there is no network request that sends the password, and it works offline too. Only your custom policy (length rules, blocklist) is stored locally; it never contains a password.
Checking password strength in code
To add live strength checks to your own signup or password-change form, use a zxcvbn port for your language:
<!-- CDN -->
<script src="https://unpkg.com/[email protected]/dist/zxcvbn.js"></script>
<script>
const res = zxcvbn('P@ssw0rd!');
console.log(res.score, res.crack_times_display);
</script>
// npm i @zxcvbn-ts/core
import { zxcvbn } from '@zxcvbn-ts/core';
const result = zxcvbn('P@ssw0rd!');
console.log(result.score, result.guesses_log10);
composer require bjeavons/zxcvbn-php
<?php
require __DIR__ . '/vendor/autoload.php';
use ZxcvbnPhp\Zxcvbn;
$zxcvbn = new Zxcvbn();
$res = $zxcvbn->passwordStrength('P@ssw0rd!');
echo $res['score'];
pip install zxcvbn
from zxcvbn import zxcvbn
res = zxcvbn('P@ssw0rd!')
print(res['score'], res['crack_times_display'])
go get github.com/nbutton23/zxcvbn-go
package main
import (
"fmt"
zxcvbn "github.com/nbutton23/zxcvbn-go"
)
func main() {
res := zxcvbn.PasswordStrength("P@ssw0rd!", nil)
fmt.Println(res.Score, res.Guesses)
}
# Add dependency
cargo add zxcvbn
use zxcvbn::zxcvbn;
fn main() {
match zxcvbn("P@ssw0rd!", &[]) {
Ok(estimate) => {
println!("score: {}", estimate.score()); // 0..4
if let Some(times) = estimate.crack_times() {
println!("offline: {:?}", times.offline_slow_hashing_1e4_per_second());
}
}
Err(err) => eprintln!("zxcvbn error: {err}"),
}
}
Scores and pattern estimates may differ slightly from this page depending on library versions, but the principles are the same. For server-side checks, also enforce a length cap and rate limiting so oversized inputs can't be used to burn CPU.
Frequently asked questions
How does this password strength checker work?
It uses zxcvbn, the open-source algorithm from Dropbox: the password is matched against common-password dictionaries, English word lists, keyboard walks, sequences, dates and repeat patterns. The estimated average number of guesses an attacker needs is mapped to a 0–4 score and crack-time estimates.
P@ssw0rd looks complex — why is it "very weak"?
It is one of the most iconic weak passwords in breach corpora. It appears directly in zxcvbn's dictionaries, and capitalization plus leet substitutions (a→@, o→0) are recognized automatically. Varied characters with a fully predictable structure is exactly what rule-based attacker dictionaries try first.
How long should a password be?
When randomly generated, 12+ characters typically defeats online attacks, while 16+ withstands offline GPU cracking for many years. Length matters more than character complexity: a random 20-character lowercase string beats a 10-character mix of all four classes.
Why separate offline and online crack times?
The attack scenarios differ: after a database breach, an attacker can try hashes locally on GPUs at billions of guesses per second; against a live login, rate limiting allows only a handful per second. The same password can survive a trillion times longer in one scenario than the other — hence both are shown.
Are my inputs stored anywhere?
No. Your password lives only in your browser's memory and disappears on refresh. Only your custom policy settings (length rules, blocklist) are kept in local storage — they never contain a password.