Most people arrive at Have I Been Pwned in a mildly agitated state, type an address into the box, and get back either a calm green panel or a long list of company logos, some of which they remember signing up to. The site does that one job extremely well. What it does not do, by design, is explain what the list means or what you are supposed to do next, and that gap is where nearly all the panic lives.
It is worth saying plainly before anything else that this is one of the genuinely good free things on the internet. It is run as a public service, it is unusually careful about what it claims, and it is cited in official advice: the UK National Cyber Security Centre points individuals and families towards it in its own guidance on data breaches. Trusting the results is reasonable. Understanding them takes a bit more.
So this is the part the site leaves to you. What each entry is actually telling you, why some results stay hidden until you prove the address is yours, how the password checker manages to answer a question about your password without ever receiving it, and the handful of things no breach index can tell you no matter how carefully you read it.
What the site is, and why the honesty is the point
The service aggregates data from breaches and makes it searchable by email address. The interesting work is in what happens before an entry appears. Incidents are assessed for legitimacy: whether the affected service has acknowledged it, where the data came from, whether its structure is internally consistent, what evidence sits inside the data itself, and the track record of whoever is distributing it.
Where that assessment cannot establish legitimacy beyond reasonable doubt, the breach is not quietly dropped. It is flagged as unverified and listed anyway, on the grounds that it still contains real personal information that real people want to know about. The same instinct runs through the other flags an entry can carry. A breach can be marked fabricated, meaning the data is unlikely to have come from the service it is attributed to even though genuine addresses are mixed into it. It can be marked as a spam list, meaning the data did not come from a security compromise at all but from someone assembling marketing lists. It can be marked as sourced from a malware campaign rather than a compromise of a company.
One more category is worth knowing because it behaves differently from the rest. Stealer logs come from malware running on infected machines, quietly recording email addresses, passwords and the site each one was typed into. That is not a company losing your data. That is a device losing everything typed on it, which is a considerably worse problem and points at a machine rather than a vendor.
Entries can also be retired. If it can be established that a set of data is genuinely no longer circulating, it is removed permanently rather than left on your record forever. That is rare, and it is the exception that proves how little any index can normally promise about what has stopped moving.
An index that only listed the clean, confirmed, tidy breaches would be smaller, tidier and far less useful. The flags exist so that messy data can be shown honestly rather than hidden.
Reading your results properly
A search returns two separate things, and they are not the same kind of evidence.
Breaches are the main list. Each entry carries a title and the domain it is attributed to, two dates, a count, a description and a set of data classes. The two dates matter more than people notice. The breach date is when the compromise is believed to have happened and is often imprecise, sometimes wildly so. The added date is when the data was loaded into the index, which can be years later. A breach dated 2016 that appeared in the index last month is old data circulating in a new place, and it explains why you might get an alert about something ancient. The count is the number of addresses actually loaded, which is frequently lower than the figure quoted in news coverage of the same incident.
The data classes are the most important line on the entry and the one most people skim past. A data class is simply an attribute of a record that was compromised, listed alphabetically: email addresses, passwords, usernames, password hints, physical addresses, dates of birth, and so on. Read that line as your work list. An entry showing nothing but email addresses is a spam and phishing exposure and very little else. An entry that includes passwords is a different situation entirely and you should assume the worst about anywhere you reused that password. An entry with dates of birth, physical addresses or government identifiers is a third thing again, because those cannot be changed the way a password can.
One caveat on data classes: they describe what the breach contained, not what your particular record contained. If a company leaked passwords for some accounts and only addresses for others, the entry lists both. It is a ceiling on your exposure rather than a description of it.
Pastes are the second list, and they are weaker evidence. A paste is content posted to a public sharing site such as Pastebin, and the index picks up addresses appearing in them. Finding yourself in one does not mean a company was breached. It usually means somebody dumped a list of addresses in public, possibly assembled from breaches you are already aware of. What it does tell you is that your address is circulating in the places where people trade this material, which is worth knowing even though it names no culprit.
Then there is a category you will not see at all unless you go looking. Some breaches are classed as sensitive, because simply being listed in them could harm someone if the wrong person found out. Dating sites, adult sites and certain forums fall into this. The public search will not return them, and the public API returns no addresses for them whatsoever. To see them you sign in to the dashboard, which involves proving you can receive email at the address you are asking about. That friction is deliberate and correct: it stops anyone typing your address into a public box to learn something private about you. It also means that if you are doing a serious audit of your own address, the anonymous result you got is incomplete by design, and you should do the verification step.
Finally, expect at least one entry for a service you have never heard of. The usual explanations are that another company acquired the data, that the service rebranded at some point, or that somebody signed your address up. If that is the part bothering you, working out who actually leaked your address is a separate exercise with its own methods.
The password check, and why your password stays on your machine
Pwned Passwords is a separate tool that answers a narrower question: has this exact string appeared in breached password data, and how many times. It exists mainly so that services can block reuse of known-broken passwords, and the corpus is published for that purpose.
The mechanism is worth understanding, because it is the reason the tool is safe to use. Your password is hashed with SHA-1 in your browser. Only the first five characters of that hash are sent to the range endpoint. The server responds with the suffix of every hash it holds that begins with those five characters, each one followed by a count of how many times it has been seen. A typical response contains in the region of 800 lines. Your browser then scans that list locally to see whether the rest of your own hash is in it.
The server therefore never receives your password, and never receives a complete hash of it either. It sees a prefix shared by hundreds of different hashes and has no way of telling which one you cared about, or even whether the answer it just gave you was yes or no. Cloudflare, which serves the API, describes the property as the service never learning enough about an unbreached password hash to be able to attack it later.
Two refinements make the guarantee sturdier. The API supports a padding option that inflates every response to a random number of records between 800 and 1,000, with the filler entries carrying a count of zero so clients can discard them. That exists so an observer watching only the size of the encrypted response cannot infer anything from it. The documentation also advises waiting until the whole password has been entered before checking, rather than querying as each character is typed, because a stream of prefixes narrows things down in a way a single prefix does not.
Reading the number it gives back takes a little care. The count is how often that exact string appears across the corpus, not how often anyone attacked you. A password appearing millions of times is in every cracking dictionary in existence and is effectively public. A password appearing once is not a clean bill of health, and is still a strong reason to change it. A result of zero means only that the string is not in this corpus, not that it is strong. Long unique passwords generated by a manager will read zero, and that number is not the reason they are safe.
The underlying idea is now formal guidance rather than folklore. NIST's digital identity guidelines require that a new password be compared against a blocklist of values known to be, in their words, "commonly used, expected, or compromised", and that a match be rejected with the reason given. The same document tells verifiers not to require periodic password changes at all, but to force a change when there is evidence the authenticator has been compromised. That is exactly the right mental model to apply to yourself: rotating everything on a schedule is theatre, changing what is known to be exposed is not.
What a breach result cannot tell you
Four limits, all of which people routinely read past.
- It cannot tell you who has your data now. An entry names the service the data is attributed to. It says nothing about how many copies exist, who bought them, or which broker merged them into something larger.
- It cannot tell you whether the data is still circulating. Retirement of an entry is the rare exception. For everything else, the honest assumption is that anything published once remains available to anyone who wants it.
- It cannot tell you whether your account was accessed, or whether your specific password was among those exposed. Both of those live in the breached company's logs, not in a public index.
- It cannot tell you that you are safe. A clean result means nothing known here. Plenty of breaches are never disclosed, never traded publicly, or surface years afterwards.
The mirror image is also true, and it calms people down more often than it should need to. A long list is not proportional to your risk. Six entries that leaked nothing but addresses from marketing databases are less serious than one entry that leaked passwords, and far less serious than one that leaked identity documents. Sort by what was taken, not by how many rows are on the screen.
What to do with the results
The response is not really about the result, it is about what the data classes told you. In rough order of urgency: change the password on any breached site and everywhere you reused it, put a second factor on your email account before anything else because it is the reset mechanism for everything you own, expect a wave of phishing that quotes real details from the breach, and check anything holding money for small unfamiliar charges rather than large ones.
That deserves more room than a paragraph, so the full what-now checklist walks through it in order with the reasoning attached. The single most common thing that arrives after an old breach surfaces is an email quoting a password you genuinely used years ago and demanding payment, and it is worth knowing in advance why those messages are recycled breach data rather than evidence of anything.
Notifications, and the version you can forget about
Searching once tells you about the past. The notification service is the part that keeps working: you submit an address, click a verification link to prove it is yours, and get an email when that address turns up in something newly loaded. It is free, and it is strictly better than remembering to check, because the value of breach news decays quickly. Knowing within days that a password is circulating is a manageable problem. Finding out a year later usually is not.
If you own a domain, there is a domain-level search that shows every address on it once you have proved ownership of the domain itself, with a paid subscription required above a certain size. That is the tool to use if you have spread your sign-ups across addresses on your own domain, since checking them one at a time stops being practical quickly.
The honest limit on all of this is that an alert can only fire when a breach reaches the index. Some arrive within days of an incident, some arrive a decade later, and some never arrive at all. Notifications shorten your reaction time, they do not guarantee you a warning.
The privacy asymmetry worth understanding
The two searches on the site have genuinely different privacy properties, and it is worth being precise about the difference rather than treating the whole site as one thing.
Searching an email address is an ordinary server-side lookup. You send the complete address, and the server has to resolve it in order to tell you which companies it appeared in. The site states that nothing is explicitly logged beyond standard analytics and application monitoring. That is a policy, held by an operator with a long and good record, and it is a perfectly sensible thing to rely on. It is still trust.
The password check is a different category. Its protection is structural rather than promised. Even a hostile server, or somebody watching the connection, learns only that you asked about one of several hundred hashes sharing a prefix. No policy has to hold for that to be true.
This is not a criticism of the address search, because the two problems are not equivalent. A useful breach result has to name the companies, and naming them requires the server to know the address. The tradeoff is inherent to the question rather than a sign of carelessness. It does mean one practical thing, though: verifying your address so you can see sensitive breaches hands over more information, not less, and it is a reasonable trade to make knowingly rather than by accident.
The longer-term lesson from a page full of entries is usually structural too. The reason one company's carelessness reaches into the rest of your life is that you gave the same identifier to all of them, which turns your address into the key that joins those datasets together. Giving each service its own forwarding address does nothing for the addresses already on that list, and anyone claiming otherwise is selling a time machine. What it changes is what the next breach costs: one address to burn, one company obviously responsible, and nothing to join.
The real value of a breach index is not that it makes you safe. It is that it converts a vague background dread into a list with dates and data classes on it, and a list is something you can work through.