Type a candidate into the common password blacklist checker and you learn in a moment whether it sits on a list of bad passwords that attackers try first. A match means the password should be rejected before it ever protects an account, because common passwords are the cheapest thing for an attacker to guess. The same check is how any service can blacklist common passwords at account registrations, and how you can test your own choices before you commit to them.
How a password blacklist works and why it matters
A password blacklist is a stored set of passwords that a system refuses to accept. Instead of judging how complicated a string looks, it asks a simpler question: has this exact string, or a trivial variation of it, already been used a million times by other people? That question is more useful than it sounds, because password strength rules alone happily accept Password1! even though it is one of the first guesses any attacker will try. Use the free password similarity comparator to confirm everything looks correct before you rely on it elsewhere.
Blacklists matter for three reasons that show up again and again in security guidance:
- Attackers work from lists. They rarely guess at random; they replay the most common password entries against thousands of accounts.
- Humans are predictable. Asked to add a capital letter, a digit and a symbol, most users produce the same handful of patterns.
- Reuse spreads damage. Passwords exposed in data breaches are tried against every other site the same person uses.
What NIST recommends
The NIST Special Publication 800-63-3, the Digital Authentication Guidelines, tells verifiers to compare new secrets against a list of known-bad values. The guidelines name three typical sources: passwords obtained from previous breach corpora, dictionary words, and context-specific words such as a user name or the service name. Treat the guidelines as a floor for authentication design, not a ceiling.
How the common password blacklist checker works, step by step
When you check common password candidates, the lookup follows the same order every time. Here is what happens behind the field:
- The candidate is trimmed and converted to a single case so that uppercase and lowercase spellings of one word count as the same password.
- Trailing digits and symbols are stripped, and look-alike characters are mapped back to letters (the normalization step explained below).
- The cleaned value is looked up in the chosen password list.
- You get a verdict: found, so avoid it, or not found, so it passed this particular test.
A "not found" result is only a statement about one list. It does not prove the password is good, and you should keep it unique to a single login.
Worked example: Sunshine2024!
Take the candidate Sunshine2024!. It is 13 characters, has a capital, digits and a symbol, and any basic composition rule would approve it. After normalization it becomes sunshine, a word that appears on every serious list of weak passwords, so the checker flags it. Its SHA-1 hash is FC0E831DFA0424589F96EF3D5134AE4302940707, which matters for the privacy model described later.
Password lists and wordlist sources
Every checker is only as good as the password list behind it. Three kinds of source dominate:
| Source type | Example | Typical size | Best used for |
|---|---|---|---|
| Curated common-password list | SecLists most common password files | 100 to 1,000,000 entries | Fast client-side blocking |
| Breach corpus | Pwned Passwords | Hundreds of millions | Blocking known leaked credentials |
| Organization terms | Custom banned password list | Up to 1,000 terms | Blocking company-specific guesses |
SecLists and the rockyou family
SecLists, maintained by Daniel Miessler, collects the wordlist files that security teams use for both defense and cracking passwords during authorized testing. The collection includes the classic rockyou files, keyboard-walk patterns, default credentials, months and seasons, and leaked databases. For a blocking use case, the "most common" slices (the top 100 up to the top 1,000,000) are the practical choice, since a smaller list loads faster in a browser. If you need more material, Weakpass publishes much larger dictionary files.
Building your own password lists
Your own password lists can be as simple as a text file with one entry per line, like hunter2 and password123. Add the names of your products, your city and your internal project codes, then deduplicate the file before loading it.
Pwned Passwords and breached password checks
Pwned Passwords is a huge corpus of previously breached passwords made free for anyone to use. Where a curated list says "this is a popular choice," this corpus says "this exact value has appeared in a real data breach and was leaked to the internet." That makes it the stronger signal against credential stuffing, where attackers replay breached email and password pairs against other sites.
The service is open source, you can download the full set to run it offline, and it answers billions of requests a month through a cache-friendly design. If a password turns up there, treat it as compromised passwords material: never use it, and change it immediately everywhere you have used it.
K-anonymity and privacy when you check
The obvious worry is sending your password to a website to find out whether it is safe. The answer is k-anonymity. Your browser hashes the password locally with SHA-1, then sends only the first five characters of the hash to the API. For Sunshine2024! that prefix is FC0E8. The server returns every matching set of suffixes, and your device compares the rest. The full password and its complete hash never leave your machine, which is what makes this a sound privacy model for a public lookup.
Client-side validation vs server side blacklist checks
The lookup the checker performs can run in two places, and each has a distinct job. Client-side validation gives users instant feedback and clean password validation and costs your server nothing, but anyone can bypass it by editing the page. The server side check is the one you can trust, so it is advisable to run the lookup there as well and treat the browser check as a courtesy.
Why a bloom filter keeps the list small
Shipping a million-entry list as plain text to every visitor is wasteful. A bloom filter solves that by storing a compact bit array that can answer "possibly on the list" or "definitely not on the list." It never misses a real entry, but it can produce a small number of false positives. Libraries such as NBP pair the filter with compression, then keep it in localStorage as a cache so the file downloads only once. The required array size follows this formula:
$$m = -\frac{n \ln p}{(\ln 2)^{2}}$$
Here \(n\) is the number of passwords, \(p\) is the false-positive rate you accept, and \(m\) is the number of bits. For a list of 250,000 passwords at \(p = 0.01\), you get \(m = 2{,}396{,}265\) bits, about 292.5 KB, with 7 hash functions. Tightening to \(p = 0.001\) grows it to roughly 438.8 KB. You are trading a few hundred kilobytes against how often a good password is wrongly blocked.
Banned password list in Microsoft Entra and Active Directory
Enterprise identity platforms apply the same idea at the directory level. In Microsoft Entra password protection, two lists work together, and a banned password list check runs whenever a user performs a password change or password reset.
Global banned password list
The global banned password list is applied automatically to all users in a tenant. Alongside it, banned passwords you define yourself apply too. The global list is built from security telemetry rather than any external data source, and the contents are deliberately not published so that attackers cannot read it. There is nothing for an administrator to enable.
Custom banned password list
The custom banned password list lets an organization add its own entries, capped at 1,000 terms. Good entries are brand names, product names, office locations and abbreviations that mean something inside the company. Block the base term only: banning "Contoso" is more efficient than banning "Contoso!1", "Contoso@London" and every other combination.
Normalization and fuzzy matching
That shortcut works because of normalization. Before comparing, the system converts case and maps common substitutions such as 0 for o, then applies fuzzy matching to catch near misses and variants. The password is then scored: each banned term found earns one point, each remaining unique character earns one point, and a password needs at least five points to pass. A low score blocks the change.
Running a banned password list check on Maplewood#7421
Priya Raman manages IT for a 38-person dental practice called Maplewood Dental, and the front-desk team has asked to share one login for the booking system. She proposes Maplewood#7421, built from the practice name and the last four digits of its phone number. It meets the vendor's rules: 14 characters, a capital, a symbol and digits.
She runs it through the checker against the top 100,000 entries of a SecLists most-common file first. The verdict is not found, which looks reassuring until she remembers that this list knows nothing about her office. Next she switches to a banned password list that holds her own terms: maplewood, dental and the town name ridgefield.
This time normalization strips the trailing #7421 and lowercases the rest, leaving maplewood, an exact hit on her custom entry. The blacklist check returns banned. That matters because the NIST 800-63-3 guidance singles out context-specific words, such as the service or organization name, as values a verifier should reject.
| Check | List used | Result |
|---|---|---|
| 1 | Most common, top 100,000 passwords | Not found |
| 2 | Custom list with 3 practice-specific terms | Banned (matched maplewood) |
Priya rejects the candidate and re-runs the check with a four-word random phrase, tundra plank velvet orbit, which clears both lists. She then adds the practice's three other staff-room nicknames to the custom list, so the next shared account cannot repeat the mistake.
Weak passwords, password spray attacks and brute-force risk
Understanding the attack shapes explains why blacklists exist. In a brute-force run, an attacker hammers one account with many guesses and usually trips a lockout. In password spray attacks, the same few weak choices are tried against every account once, staying under the lockout threshold. A password spray works precisely because some user in a large organization chose a predictable value.
Blocking the most common password choices at the source takes that opportunity away. It also reduces password reuse exposure, since a person cannot reuse a value the system refuses to accept in the first place.
Password protection for your login after a blacklist check
A "found" verdict means picking a new password; a "not found" verdict is only the first layer. Pair the result with multifactor authentication so a guessed value alone cannot open an account. Choose strong passwords that are long and random, and let a password manager generate and store a unique one for each service, because that removes the human pattern that lists exploit.
- Check each new secret against a common-password list at registration and again at every change.
- Reject any password found in a breached set, and avoid a dictionary word with digits tacked on.
- Keep an eye on your email for breach notifications and rotate exposed credentials at once.
- Treat the blacklist as a filter, not a guarantee, since no library can know every bad choice.
The risk you are managing is simple: a short, predictable password gets guessed from a list, and your identity goes with it. Apply the check, add a second factor, and keep every password different.
Integrate a password checker API into your service
If you run a site, you can integrate a lookup into your service with a few lines. A typical browser library exposes an initialization call and a check call, for example:
NBP.init("mostcommon_100000", "collections/", true);
NBP.isCommonPassword("hunter2");The first line selects the list and enables the cache; the second returns whether the value is common. Pair it with the range API described above for breach data, and use validation on the server so the rule cannot be skipped. If you build a custom wordlist, name it with its entry count so the loader knows how large to make the filter.
Whatever you choose, remember the purpose: to stop users from picking a password an attacker has already tried. Sound password protection here is cheap, quick and invisible to the person typing.
Frequently Asked Questions
- What's on this blocklist?
- The same consolidated common-passwords list this site's other tools use -- widely known weak passwords, keyboard walks, and frequently breached values (things like "password123", "qwerty", "letmein"). See this site's own documentation for how that list was assembled and verified.
- Why check against a blocklist instead of just scoring strength?
- A blocklist check answers a different, more direct question: "has this exact value already been seen and blocked by real systems?" A password can theoretically score "strong" on length and character variety while still being a known compromised value -- blocklist checks catch that case specifically, which is why NIST SP 800-63B recommends screening against a blocklist as step one, before any complexity scoring.
- My password isn't on the blocklist -- does that mean it's strong?
- No -- a blocklist can only catch the specific values it contains, not every weak pattern. Passing this check just means your exact password isn't a known compromised entry; also run it through the Password Strength Checker or Password Pattern Analyzer for a fuller picture.
- Does this check for near-matches, like "Password1!" vs "password"?
- No -- this specific tool checks for an exact (case-insensitive) match only. Small variations of a common password can still be easy to guess in practice, since attackers routinely try common mutations (capitalization, appended digits, trailing symbols) of blocklisted values.
- Is my password sent anywhere?
- No. The entire check runs locally in your browser against data already loaded with the page -- nothing is transmitted to a server or stored.