The paradox of asking a server about your password
Here is the problem that stops every sensible person from using a breach checker: the only way to find out whether your password leaked is to somehow ask — but asking means sending the password, and sending the password to a service whose entire purpose is knowing leaked passwords is an act of trust nobody should be asked to perform. It is a genuine catch-22. Refuse to ask, and you stay ignorant of a risk that matters. Ask naively, and you have handed your credential to a stranger.
The answer to that paradox is five characters. Not five characters of the password — five characters of its SHA-1 hash. Troy Hunt's Have I Been Pwned range API, built with Cloudflare, implemented a scheme called k-anonymity: your browser hashes the password, sends only the first five hex characters of that 40-character digest, and the server answers with every breached-hash suffix that starts with those five. Your password, your full hash, and any proof of which suffix you cared about — none of it crosses the wire. The checker on this page implements exactly that protocol, and this article explains why five characters are safe when forty would not be.
One framing before the mechanics, because it is the mental model that makes everything else click: the server never learns what you asked. It learns that somebody, somewhere, asked about a hash prefix. It cannot learn what password the prefix belongs to, because thousands of passwords share each prefix. The anonymity comes from the crowd — that is the 'k' in k-anonymity, and it is the same idea that lets a library tell you whether a book exists without recording which page you intended to read.
Running a check without leaking anything
Type or paste the password
The field never displays the characters — but more to the point, nothing you type is stored, logged, or queued for transmission. The input exists only in your tab's memory.
The hash happens locally
Your browser computes SHA-1 over the password, entirely on your device, using the Web Crypto API. A 40-character hexadecimal digest appears in memory. It has not gone anywhere.
Five characters travel
The tool takes the first five hex characters of the digest — 16^5 is one million possible prefixes — and makes exactly one HTTPS request: /range/{prefix} to the Pwned Passwords API.
A crowd of decoys comes back
The API responds with hundreds to a couple thousand lines: every breached-password hash suffix sharing that prefix, each with its breach-appearance count. Your answer is in that crowd, indistinguishable from its neighbors.
The match happens locally
Your browser scans the returned list for the remaining 35 characters of your hash. Found means the password appears in known breach corpora, along with how many times; not found means it does not appear in the data set.
Read the verdict, then act
A hit is a retirement notice for that password, not a panic event. The next section covers exactly what to do — the short version is that a breached password must be treated as known to attackers, everywhere you used it.
How five characters protect forty
The number five is not arbitrary, and the arithmetic explaining it is worth thirty seconds. SHA-1 digests are 40 hexadecimal characters — 160 bits. Sending all 40 to a lookup service would tell the service exactly what you asked about: a trivial database search, or even a live computation, would reveal your password. Sending none of it is useless. The protocol needs the smallest slice that still narrows the answer — and a five-character hex prefix describes one millionth of the hash space (16^5 = 1,048,576).
One millionth sounds tiny, but against a corpus of hundreds of millions of breached passwords, a millionth of the space is still a crowd. When we queried the prefix 5BAA6 while writing this article, the API returned 1,977 matching hash suffixes. Anybody observing that request — a hostile network operator, a logging proxy, the API itself — learns only that someone checked a password whose hash begins 5BAA6. There are 1,976 other equally plausible candidates in the response alone, and billions more in the full space. The observer's certainty about what you typed is roughly one in thousands, before considering that prefixes can be queried deliberately as decoys.
The system has a second anonymity layer worth knowing about: response padding. The range API accepts a padding parameter that inflates the response with additional decoy suffixes, so even the response size leaks less about whether your prefix is a densely-populated one. And a rate-limiting side effect helps too: the API is hammered with requests all day from every client, so your single prefix request is a drop in a global river. k-anonymity plus traffic volume plus padding — privacy achieved by making your question indistinguishable from a crowd of nearly two thousand questions.
One password, followed through the protocol
Let's trace three checks end to end, with live numbers we pulled from the range API while writing this page. These are real responses, not illustrations.
Input
Password: password SHA-1: 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 Prefix sent: 5BAA6 (35 characters stay home)
Output
The 5BAA6 range returned 1,977 hash suffixes. Among them: 1E4C9B93F3F0682250B6CF8331B7EE68FD8:52372427 Verdict: PWNED — seen 52,372,427 times in breach corpora. That number is not a typo. 'password' has shown up fifty-two million times in dumps.
Input
Password: P@ssw0rd SHA-1: 21BD12DC183F740EE76F27B78EB39C8AD972A757 Prefix sent: 21BD1
Output
Suffix 2DC183F740EE76F27B78EB39C8AD972A757 appears with count 6,421,042. Verdict: PWNED — 6.4 million appearances. The leetspeak substitution that feels clever to a human is a single dictionary entry to a cracking rig.
Input
Password: correct horse battery staple SHA-1: ABF7AAD6438836DBE526AA231ABDE2D0EEF74D42 Prefix sent: ABF7A
Output
Suffix AD6438836DBE526AA231ABDE2D0EEF74D42 appears with count 391. Verdict: technically PWNED — 391 appearances. Yes, even the xkcd passphrase is in the corpus, because millions of people read the same comic and adopted the same example. The lesson is subtle and important: uniqueness matters as much as length.
That third result is the most instructive one on this page. 'correct horse battery staple' is long, memorable, and structurally sound — and it is still burned, because it became popular. A breached-password list is not a list of weak passwords; it is a list of known passwords. Anything that has circulated — dictionary words with common substitutions, famous passphrases, lyrics, anything typed into a public site that later leaked — eventually lands in the corpus. The only password guaranteed absent is one nobody else has ever used, which is precisely what a Password Generator produces.
What a hit does and doesn't mean
The honest limitations, stated flatly, because a security tool that overstates its coverage is worse than no tool:
- Coverage is 'known breaches,' not 'all breaches.' The corpus is assembled from dumps that have been collected, parsed, and published. Passwords inside unreleased or undiscovered breaches do not show up. A clean result means 'not in the known sets' — never 'safe.'
- A hit does not mean your specific account was breached. It means that exact password has appeared in breach data — possibly from a service you never used, typed by a stranger who happened to choose the same string. Treat it as burned regardless; attackers do not distinguish whose password it was.
- The count is appearances, not incidents. 52 million appearances of 'password' aggregates across many dumps and many normalization passes. Directionally it is exactly right; forensically it is a rough number.
- Strength and breach status are different axes. A 25-character random string from a breached password manager dump would score 'pwned' while being unguessable; 'Tr0ub4dor&3' scores not-pwned-if-novel while falling to a modest GPU in under a day. Check both properties with both tools.
- Live credential checking is still bad practice at scale. k-anonymity protects the individual query. For organizations, the right move is policy-level screening — reject breached passwords at password-set time, which most identity providers now support natively against this same API — rather than harvesting staff passwords for a one-time audit.
NIST's Digital Identity Guidance (Special Publication 800-63B) is the reason this style of check exists at all: it explicitly recommends that verifiers screen new passwords against known-breached-password sets. The recommendation comes with a companion fact worth remembering — the guidance also retired forced periodic password changes and complexity rules in favor of length and breach screening. Modern password hygiene is: long, unique, screened against breach corpora, changed when a screen says so. That is a shorter rulebook than most people carry in their heads.
Who runs breach checks
The daily users are split between two very different populations, and the tool serves them differently.
Individuals after a breach headline. A service announces a dump; the news reaches you on a Tuesday; by Tuesday evening you want to know whether the password you used there — the one you definitely reused somewhere else — is now public property. The five-second check converts a vague dread into a specific to-do list. Security-aware professionals check candidate passwords before adopting them, and periodically re-check the passphrases guarding their most valuable accounts, because the corpus grows: a password that was clean in 2023 can be in a 2026 dump. Developers and product teams use the API this tool wraps — it is the same one identity platforms call at password-set time to reject burned passwords before they are ever accepted. Students in security courses encounter the protocol as the canonical example of privacy-preserving queries; the k-anonymity range API shows up in coursework the way the TCP handshake does, and a tool that lets you watch a real query go by has pedagogical value no diagram matches. Journalists and researchers checking credential lists referenced in stories make up a quieter fifth group.
Timing-wise, usage spikes after every major breach disclosure, and the pattern repeats on the annual security-training calendar that rolls through corporate October. The tool is deliberately instant and ephemeral for those moments — no account, no history, no trace of what was checked.
Breach checkers vs. strength meters
| Question it answers | Breach checker (this tool) | Strength meter |
|---|---|---|
| Core question | Is this password already known to attackers? | How hard would guessing this password be? |
| Method | Lookup against real breach corpora via k-anonymity | Entropy estimation over length, charset, patterns |
| Blind spot | Unbreached but guessable passwords pass | Breached but novel-looking strings can score well |
| False comfort risk | 'Not found' read as 'safe' | High score read as 'unique' |
| Best practice | Run both | Run both |
The mirror-image failure modes deserve emphasis, because most password advice collapses them into one question. A strength meter rewards 'CorrectHorseBatteryStaple2026!' with a green bar and cannot know the base string is in the corpus. A breach checker flags the corpus hit and cannot tell you that your not-found password is 8 characters of keyboard-walk. Together they cover each other's blind spot, which is why this tool links straight to the Password Strength Tester and vice versa. And when either tool sends you shopping for a replacement, the generator is the third leg of the tripod.
Why we can't see your password
This deserves the most careful writing on the page, because it is the entire product. The chain of custody for your input: typed into a field that exists in your browser's memory; hashed locally by the Web Crypto API; reduced to a five-character prefix; sent as one HTTPS request to the Pwned Passwords range API; compared locally against the response; displayed. At no point does the password, the full hash, or your identity travel to any server we operate. There is no backend for this tool. There is nothing to subpoena, breach, or resell, because we never possessed the thing that would be valuable.
Compare that with the naive alternative — a form that posts the password to a server which checks it against a local corpus. That design works, and sites still ship it, and every one of them is one log misconfiguration away from building a new breach corpus out of the exact passwords people were trying to protect. The k-anonymity design is not a nicer version of that. It is a categorically different shape, where the privacy property holds even if every operator involved is hostile, because the data never exists outside your device in revealable form.
Two footnotes for the thorough. First, even with this design, the healthiest habit is checking candidate passwords rather than your entire live credential set in one sitting — not because the protocol leaks, but because good password hygiene means minimizing the number of places any password exists at all, including in your short-term memory while tabbing between a checker and a login page. Second, if you want to verify our claims independently, open your browser's network tab while running a check: you will see exactly one API request, and its path will contain five hex characters. Trust, but inspect — the network tab is the receipt.
Questions about breach checking
Is it safe to type my real password into a breach checker?
With this tool, yes — by architecture, not by promise. Your password is hashed locally with SHA-1, and only the first five characters of that hash are sent to the range API. The full hash, and the password itself, never leave your device. Even a malicious operator of the API could not reconstruct your password from a five-character prefix, because thousands of passwords share it.
What does 'pwned' actually mean?
It's internet slang, originally a typo of 'owned,' meaning compromised or taken over. In this context a 'pwned password' is one that appears in a known data breach corpus — plaintext or recoverable credentials dumped from hacked services. Have I Been Pwned popularized the term for its database of breached credentials.
My password showed up in a breach. What should I do?
Stop using it everywhere, immediately. If you reused it across sites, change it at every site — attackers take breached passwords and try them against email, banking, and social accounts in automated 'credential stuffing' attacks. Replace it with a unique password per account, ideally generated and stored in a password manager. The breach you found is rarely the only one it appears in.
My password wasn't found. Does that mean it's strong?
No — the two questions are unrelated. This check compares against known breach corpora only; a password can be absent from every dump and still fall to brute force in minutes if it's short or patterned. Pair this check with the Password Strength Tester, which estimates guessability. Absence from breach lists is one good property, not proof of safety.
Do you send my password to a server?
Never. The tool hashes your input in your browser and transmits only the first five hexadecimal characters of that SHA-1 hash to the range API. The password, the full 40-character hash, and any other signal about you stay on your device. That is the k-anonymity protocol described on this page.
Why does this use SHA-1? Isn't SHA-1 broken?
SHA-1 is cryptographically broken for collision resistance, which matters for signatures and certificates. For this lookup it is simply an index — the property that matters is that an attacker watching the traffic cannot reverse a five-character prefix to your password, and hash function reversibility is not the failure mode SHA-1's breaks involve. The range API uses uppercase SHA-1 as its convention; the security comes from the k-anonymity design, not from the hash's collision properties.
Can I use this to audit my whole team's passwords?
Not with live credentials, no — and you shouldn't want to. The correct professional pattern is sampling or policy-based checks: generate passwords under your policy, test that the policy blocks breached patterns, and rely on your identity provider's breached-password screening for actual user credentials. Never collect employees' real passwords into a spreadsheet for checking, even with a privacy-safe API.
Does this tool check whether my email was breached?
No. This checker tests a password against breach corpora. Checking which accounts were exposed in a breach is a different service — Have I Been Pwned's account search — which works on email addresses and requires its own privacy considerations. The two checks answer different questions: 'is this password burned?' versus 'was my account in that dump?'
Security tools that pair with this
A breach check is one step in a workflow, and the neighbors are already built. When a password fails this check — or when you want to stop memorizing and start managing — the Password Generator produces the unique strings that never appear in corpora. The Password Strength Tester covers the opposite axis, estimating guessability for passwords that are clean in breach terms. And if you want to see exactly what the checker does under the hood, the SHA-256 Hash Generator lets you hash text yourself and watch a digest appear — the same class of operation, different algorithm, fully local in both cases.
The full routine takes two minutes: generate, strength-check, breach-check, save in your manager. Do it once per account and the next breach headline becomes someone else's Tuesday.
Primary sources on the protocol
Everything in this article traces to four primary documents. If you are implementing or teaching this protocol, read them rather than us:
Sources and further reading
- Have I Been Pwned — API v3 documentation, Pwned Passwords range search(haveibeenpwned.com)
- Have I Been Pwned — Pwned Passwords overview(haveibeenpwned.com)
- NIST Special Publication 800-63B — Digital Identity Guidelines(pages.nist.gov)
- Cloudflare — K-Anonymity: anonymity in a transparent world(blog.cloudflare.com)
We cite primary sources (standards bodies, government agencies, official documentation) wherever they exist so you can verify every number on this page yourself.