Skip to main content

Password Strength Checker

See how strong your password is and get specific suggestions to improve it before you commit.

Privacy Notice

Your password is analyzed locally in your browser and never sent to any server. It's completely private and secure.

Type a password and a meter returns a score. The question worth asking is which attack that score models, because a string satisfying every character-class rule can still fall inside the first few thousand guesses of a real cracking run. This page covers what strength estimation can and cannot tell you.

Why P@ssw0rd1! scores well and dies instantly

A naive meter counts categories: length above some threshold, one uppercase, one lowercase, one digit, one symbol. P@ssw0rd1! satisfies every one of them at ten characters and turns a large fraction of registration forms green.

A cracking run does not enumerate character combinations. It starts from a wordlist and applies transformation rules, and every rule set in circulation includes leetspeak substitution. Hashcat ships best64.rule in its default rules directory precisely because those sixty-four transformations — capitalise the first letter, append a digit, append punctuation, swap a for @, s for $, o for 0 — recover an enormous share of real passwords from a modest base dictionary.

Substitution buys almost nothing. The word password has roughly four substitutable positions, so allowing each letter or its lookalike multiplies the candidate count by about 16, which is four bits. Appending 1! adds a similarly small factor. The base word itself contributes essentially zero, because it is one entry in a list the attacker tries before anything else. The meter measured the wrong quantity: not how many character types are present, but how many guesses stand between an attacker and this exact string.

Estimating guesses instead of counting character classes

zxcvbn, the estimator Dropbox published and presented at USENIX Security in 2016, inverts the approach. It searches a password for overlapping matches against several dictionaries — common passwords, English words, surnames, given names, US place names — plus dates, repeats, sequences such as abcdef, and keyboard adjacency walks like qwerty or 1qaz2wsx. It then finds the cheapest way to assemble the whole string out of those pieces and reports the number of guesses that decomposition implies.

That framing produces answers a class-counting meter cannot reach. It recognises Tr0ub4dour&3 as a dictionary word with substitutions and prices it as such. It recognises correcthorsebatterystaple as four common words and charges four dictionary lookups rather than crediting 25 characters. It recognises an eight-character keyboard walk as one pattern rather than eight independent choices.

The limitation is inherent to the method: an estimator only sees patterns it was taught. Your employer's name, a local sports team, this year's number appended to an internal project codename — none of those appear in a general-purpose dictionary, so they score far higher than they deserve against anyone who built a targeted wordlist first. A guess estimate is a ceiling on the work a generic attack needs, not a floor on the work a specific one does.

Online and offline attack rates differ by a billion

Any claim about how long a password takes to crack is meaningless without a guess rate, and the plausible rates span nine orders of magnitude. Which one applies is a property of the defender's infrastructure, not of the password.

Against a login endpoint with rate limiting and lockout, an attacker gets a few attempts per minute per account. Credential stuffing scales that sideways across millions of accounts, but the per-account budget stays tiny, which is why the passwords that fall to online attacks are almost exclusively ones already sitting in a breach corpus.

Against a stolen hash table, throughput depends entirely on how the password was stored. Published hashcat benchmarks put a single RTX 4090 at roughly 150 billion MD5 hashes per second and about 22 billion for SHA-256. A 95-bit random password shrugs that off; an eight-character human-chosen one does not survive the afternoon. Point the same card at bcrypt with a work factor of 12 and it manages on the order of 1,400 guesses per second — eight decimal orders of magnitude slower, purely because of the storage choice. The hash generator notes cover why a fast digest is the wrong primitive for that job.

Checking a breach corpus without disclosing the password

Reuse, rather than weakness, is what compromises most accounts, and no amount of local analysis detects it. The check that matters is whether this exact string already appears in breach data, and the standard way to run it without handing over the password is a k-anonymity range query.

Have I Been Pwned's Pwned Passwords API works like this. The client computes SHA-1 of the candidate locally, sends only the first five hexadecimal characters of that digest, and receives back every stored suffix beginning with that prefix along with a prevalence count. The client then searches the response for its own 35-character suffix. There are 16^5 = 1,048,576 possible prefixes, every one of them returns results, and a typical response carries several hundred suffixes — enough that the server learns essentially nothing about which candidate was tested.

Two aspects of that design are routinely misread. The SHA-1 is an index, not a security control: its job is to partition the corpus evenly, and its collision weakness is irrelevant to partitioning. And a hit is a fact rather than an opinion — the count says how many times this precise string has turned up in breach data. Something seen a hundred thousand times sits near the top of every attacker's wordlist no matter how many symbols it contains.

The failures a score cannot see

A meter examines one string in isolation, which structurally rules out the three failure modes behind most account takeovers. It cannot tell that the password is already in use on four other sites. It cannot tell that it is a family member's name and birth year, information that is public and near the front of a targeted list. And it cannot tell whether the service receiving it stores it with Argon2id or with an unsalted MD5.

There is a subtler problem too. The score is produced before the account exists and amounts to a prediction about attacker behaviour years out. Wordlists grow, rule sets improve, and hardware gets faster, so a rating handed out in 2018 does not carry forward. Nothing re-scores the password afterwards.

Treat the number as a filter for the obviously bad rather than a certificate for the good. The controls that genuinely move risk sit elsewhere: reject known-breached values at registration, rate-limit and lock out at the login endpoint, store credentials with a memory-hard function, and require a second factor. A strength meter is a teaching aid for the person typing; it is not a security control for the system receiving it.

ThenCatch is a free developer toolkit. Learn more about us.