Loaded with a made-up sample, NotMyRealP@ssw0rd2025. Clear it and type a pattern similar to yours.
Nothing you type is sent anywhere. The checks run in this page's own code and make no network request while you type. Like every page on this site, the page also loads Google Analytics and AdSense scripts; this page's code never passes them the field's value.
The upper bound is log2(poollength) and assumes every character was picked at random. The pattern estimate is this page's own model of how many guesses a pattern-aware attacker would need. Neither is a crack time.
About this tool
This password checker shows how strong a password is by looking at it the way a guessing attacker would. It reports the length and character types, a naive entropy upper bound, and a pattern-adjusted estimate that discounts things people predictably put in passwords: common passwords, dictionary words, sequences like abc or 123, keyboard runs like qwerty, repeats like aaa, look-alike swaps like p@ssw0rd, dates and years. Everything happens in your browser. The field has autocomplete and spellcheck turned off, it is hidden until you press Show, and typing in it makes no network request.
How to use the password strength checker
- Clear the sample and type a password, or better, a password built the same way as yours (see below for why).
- Read the two numbers. The upper bound is the best case. The pattern estimate is usually lower and is the one to take seriously.
- Check the pattern list. Each pattern found is explained in plain words, with the part of the password it covers (shown only while the password is visible).
- Optionally load the word list. Press Load word list to add an English dictionary check. It downloads a public 1.7 MB file once.
How the checker works
Character pool and upper bound. The tool counts which kinds of characters appear: lowercase letters (26), uppercase letters (26), digits (10), and printable ASCII symbols including the space (33). Any other character, such as an accented letter or emoji, adds an allowance of 100, which is an assumption of this tool. Length is counted in Unicode code points, which is how NIST says length should be counted. The upper bound is log2(poollength) bits. It is only true for a password chosen completely at random, so it is labelled as an upper bound.
Pattern estimate. The checker then looks for patterns and gives each one a guess count, roughly how many tries an attacker who knew to look for that pattern would need to hit it:
| Pattern | What counts | Guesses in the model |
|---|---|---|
| Common password | An entry from a list of the 1,000 most common passwords, 4+ characters | Its rank on the list (1 to 1,000) |
| Dictionary word | An English word of 4+ letters from the ENABLE list (after you load it) | 172,823, the size of the list |
| Sequence | 3+ letters or digits in alphabet order, either way: abc, 987 | 26 (or 10 for digits) × 2 directions × length |
| Keyboard run | 3+ neighboring keys from one US QWERTY row, either way, including !@#$ | 2 × row length × run length |
| Repeat | The same character 3+ times: aaa, !!! | Size of that character's set × length |
| Year | Four digits from 1900 to 2039 | 140 |
| Date | 6 or 8 digits, or day, month and year with -, / or . | 153,720 (366 days × 140 years × 3 orders) |
Words and common passwords are matched without regard to case, then multiplied by 2 if the word is capitalized or all caps (more for mixed case), and by 2 for every look-alike swap such as @ for a, 0 for o, 3 for e or $ for s. Every character not covered by a pattern costs log2(pool) bits, as if random. The tool picks the combination of patterns that gives the lowest total, so it reports the cheapest way an attacker could describe your password. The result is shown in bits and as guesses rounded to a power of ten. The rating uses this page's own cut-offs: under 25 bits is very weak, under 40 weak, under 60 fair, under 80 strong, and 80 or more very strong. A password that exactly matches a common one is always very weak.
The common-password list is the first 1,000 entries of the list shipped with zxcvbn, an MIT-licensed strength estimator from Dropbox whose acknowledgments thank Mark Burnett for releasing his 10 million password corpus. The dictionary is ENABLE, a public-domain word list of 172,823 words. It has no word frequencies, so every word gets the same cost.
Worked example
The page opens with the made-up sample NotMyRealP@ssw0rd2025. It is 21 characters and uses all four ASCII sets, so the pool is 95 and the upper bound is 21 × log2(95) = 138.0 bits. Two patterns are found. P@ssw0rd is password, number 2 on the common list, with a capital first letter (×2) and two swaps (×4): 16 guesses, or 4 bits. 2025 is a year: 140 guesses, 7.1 bits. The other 9 characters cost 6.57 bits each, 59.1 bits. The pattern estimate is 4 + 7.1 + 59.1 = 70.3 bits, about 1021 guesses, rated Strong. Load the word list and Real is found too (172,823 × 2 guesses, 18.4 bits instead of 26.3), which lowers the estimate to 62.4 bits, about 1019. Without the patterns it would have been 138 bits; the guessable middle and end cost it about half.
Why there is no crack time
Many checkers show a time to crack. That number depends on things a web page cannot know: whether the attacker is guessing online against a login that limits attempts, or offline against stolen hashes, and how slow the hash is. NIST notes that stored passwords are "salted with a random value and hashed, preferably using a computationally expensive algorithm"; the same password falls far faster against a fast hash than a slow one. So this page shows only guesses, from a stated model.
Why length beats complexity
The US National Institute of Standards and Technology says in SP 800-63B-4 that "password length is a primary factor in characterizing password strength". Its password rules require a minimum of 15 characters for a password used on its own and 8 for one used only as part of multi-factor login, and say services "SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types)". The reason is human behavior: NIST notes that a user who might have chosen "password" would be relatively likely to choose "Password1" if required to include an uppercase letter and a number. This checker shows the same thing. A capital first letter adds 1 bit, a year adds about 7, while every extra random character adds about 6.6 bits at a 95-character pool.
Passphrases
NIST adds that "the use of passphrases (i.e., passwords with multiple words) is often an effective way to create a longer password." The words have to be picked at random, not from a quote or lyric. Try correct horse battery staple here with the word list loaded: its upper bound is 164.7 bits, but as four common words (one of them, horse, on the common list) the estimate is 79.3 bits. That is still a lot, and that is the point of random words. For random passphrases or strings, use the Password Generator.
Never reuse a password
A strong password stops being strong once it leaks. If one site is breached and you used the same password elsewhere, attackers can simply try it on your other accounts, with no guessing at all. No strength score accounts for that. Use a different password for every account and let a password manager remember them; NIST says verifiers "SHALL allow the use of password managers and autofill functionality".
Don't type your real banking password into any website
That includes this one. This page sends nothing, and you can confirm it in your browser's developer tools (F12, Network tab): typing adds no request. But any script running on a web page can in principle read a form field, and you cannot easily verify every script on every site. The honest advice is to test a password that follows the same recipe as yours, with the same length, the same kinds of words, numbers and symbols in the same places, instead of the real thing. The score will be the same, because the model only looks at the pattern.
Common mistakes
- Trusting the upper bound. It assumes randomness that human-made passwords rarely have.
- Swapping letters for symbols.
P@ssw0rdis found almost as fast aspassword. - Adding a year or a
!at the end to meet a rule. NIST's own example of predictable behavior ispasswordbecomingPassword1. - Reading a high score as safe forever. A reused or leaked password is weak whatever it scores.
Use cases
- Seeing why a password you invented scores lower than its length suggests.
- Comparing a short complex password with a longer passphrase.
- Explaining NIST's 15 and 8 character minimums to a team or family member.
- Learning why sites store a hash instead of the password; the Hash Generator shows what a digest looks like.
Frequently asked questions
No. It compares your password with an embedded list of the 1,000 most common passwords, but it does not look anything up in a breach database, because that would mean sending something over the network. A password that scores well here could still have leaked if you used it on a site that was breached.
Symbols and numbers only help when they are unpredictable. If they come from a swap like @ for a, a year, or a run like 123 or !@#, the checker treats them as part of a known pattern and charges only a few bits. Adding more random characters or random words raises the score far more.
For a password you use with a second factor, it meets NIST SP 800-63B-4, which sets 8 characters as the minimum in that case. Used on its own, NIST requires at least 15. A truly random 12-character password from all 95 printable ASCII characters has an upper bound of about 78.8 bits.
Each one uses its own model: different word lists, different pattern rules, and different assumptions about the attacker and the hash. Some only count character types, which overrates passwords like Password1!. Treat any score, including this one, as an estimate and look at which patterns it found.
Barely. A capital at the start, or a word in all caps, doubles the guesses in this model, which is 1 extra bit. That is about what attackers expect people to do. A capital in an unexpected position counts for a little more, but one more random character adds about 6.6 bits.
It checks one password at a time and keeps nothing, so there is no export or history. For a team, the better approach is a password manager that generates a different random password for each account, plus a service-side blocklist check of the kind NIST SP 800-63B-4 requires.