Is your password in a data breach?
A data breach is what happens when a service’s password database escapes into the open — and a breach corpus is the collection of passwords harvested from hundreds of those escapes, indexed so anyone can ask whether a given password is among them. If yours is, attackers already own it: it sits in wordlists that are tried automatically against every login page they can reach. This article explains how the check works without ever revealing the password, what a count of “found 52 million times” actually means, why “not found” is not a clean bill of health, and why you must never paste a password into a chatbot to ask whether it is safe. To run the check, use the Password Breach Check.
What a breach corpus is
Every major breach leaves the same residue: a database of usernames and passwords, usually stored as hashes, copied out of a company’s systems and passed around, sold or published. Individually those databases are evidence of one company’s failure; gathered together, deduplicated and indexed, they become something else — a census of the passwords people actually use. Have I Been Pwned’s Pwned Passwords corpus, the one this site’s checker queries, holds over a billion passwords from hundreds of breaches, and it grows every time a new breach surfaces. It is not a list of weak passwords compiled by theorists. It is a record of the passwords real people chose, typed and lost.
That is why the corpus is such an unforgiving mirror. A password you invented in five seconds — a name plus a birth year, a sports team plus an exclamation mark, a keyboard walk with a digit at the end — has very likely been invented in exactly the same form by thousands of other people, and if any of them used it on a breached service, it is in the corpus. Attackers do not guess passwords one at a time the way a person would. They run credential stuffing: take a list of leaked username-and-password pairs, or a wordlist of leaked passwords, and try them automatically, millions of attempts an hour, against login pages everywhere. A password in the corpus is a password that is already on the list.
How the five-character check works
Checking a password against a billion-entry database sounds like it should require sending the password to someone — and for years that was the honest objection to every breach-check service. The fix is a trick called k-anonymity, and it is simple enough to state in one sentence: the service never learns which password you asked about, because it never sees enough of it to tell. Your password is hashed in the browser with SHA-1, producing a 40-character fingerprint. Only the first 5 characters of that fingerprint are sent to Have I Been Pwned. The service returns every fingerprint suffix that shares those 5 characters — typically around eight hundred of them — and your browser looks for its own suffix in the list, locally, on your device.
Five characters is the load-bearing number. A 5-character hex prefix has about a million possible values, so each prefix is shared by roughly a thousand passwords in a billion-entry corpus — enough lookalikes that the service cannot identify your password, and few enough that the answer fits in a single small response. Nothing about the password itself crosses the network: not the password, not its full hash, not even a hint of its length. The same design is why the check needs no account, no API key and no rate limit worth noticing, and why the responses can be cached for weeks: the answer for a prefix is the same for everyone who asks. The Password Breach Check on this site implements exactly this model, in the browser, with the hash computed locally before anything is sent.
What “found N times” means — and what to do
A count above zero means the password has been seen in breaches that many times, and the number is a direct measure of how early it will be tried. A count in the millions — “password” itself has been seen more than fifty million times — means the password is among the very first guesses in every credential-stuffing run, and it should be changed everywhere it is used, starting with the accounts that protect the others: email first, then banking, then password-recovery paths. A small count is not a pass. Even a single appearance means the password is in an attacker’s wordlist, and it is usually also a sign that the password follows a guessable pattern — the same pattern that put thousands of lookalikes in the corpus alongside it.
The fix is the same at any count: replace the password with a unique one you have never used anywhere else, and store it in a password manager rather than in your head. Human memory is the reason reused passwords exist — nobody can remember a hundred distinct random strings — and a manager is the tool that makes uniqueness affordable. Generate the replacement with the Password Generator, save it in the manager, and then change the password on every service where the old one was used, starting with the ones that would let an attacker reset the others. If the same password protected several accounts, treat all of them as exposed: attackers try a leaked password against every service they can reach, not just the one it leaked from.
What “not found” does not mean
A count of zero is good news with a strict limit. It means the password has not been seen in the breaches this corpus knows about — nothing more. It does not mean the password is strong: a short password built from a dictionary word and a digit can be absent from the corpus and still fall to a guessing attack in minutes, because guessing does not need the password to have leaked first. It does not mean the password is safe: breaches take months or years to surface, and a password sitting in an unreported breach is invisible to every corpus until the day it is not. And it does not mean a reused password is fine: a password used on ten sites is one breach away from losing all ten, whatever today’s count says.
The honest way to read a zero is as one check passed out of several. The password is not known to be leaked — that is worth knowing, and it is the only thing the check can tell you. Whether it is also long enough, random enough and used in exactly one place is a separate question, and the check cannot answer it. The standard worth holding is the one in NIST’s memorised-secret guidance, listed below: favour length over complexity rules, never require periodic changes for their own sake, and check new passwords against breach corpora at the moment they are chosen — which is exactly the check this article describes. A password that is long, random, unique and not found is a good password. Remove any one of those four properties and the zero stops meaning very much.
Never paste a password into a chatbot
The most dangerous way to ask “is my password safe?” is to paste the password into a chatbot or an AI assistant and ask it directly. A chat keeps a transcript: your password would be stored on someone else’s servers, retained under their retention policy, used to train or tune models, and possibly quoted back — verbatim, in a later answer, to someone else entirely. The same applies to any website that asks you to type a password into its form and promises to judge it: unless the page hashes the password locally and shows you the mechanism, as the checker on this site does, assume the password is being sent, stored and logged. A breach check is worth doing precisely because it can be done without handing the secret to anyone — and the moment you paste the secret into a chat to ask about it, you have created the very exposure the check exists to detect.
The rule generalises. Passwords, API keys, tokens and private keys are all things that must never be typed into a chat, a ticket, a forum post or a shared document in raw form — which is why this site also has a Secret Redactor for scrubbing them out of text before you share it, and a companion article on redacting secrets before you paste. When a secret genuinely must change hands, send it through a secrets manager or an expiring, single-view share link, in a separate channel from the discussion. And when you need to know whether a password has leaked, use the mechanism built for the question: hash it locally, send five characters, and match the rest on your own device. That is the whole check, and it is the only form of the question that does not answer itself by creating a new leak.