The check itself takes two minutes: type your address into Have I Been Pwned and it lists every breach that named you. I built AliasFleet for this problem: an email-alias service that hands every site its own address, so one breach only ever exposes that one address. But "pwned" is a verdict, not a plan.
A verdict with no next step is just anxiety. I have seen people run the check, stare at the red banner, and close the tab, which fixes nothing. This piece is the part that comes after: how to run the search properly, how to read each result, and the three things to do for every breach it names. If your question is whether the site itself is safe to type your address into, that answer lives here. This one assumes you are going ahead.
Run the search
You need no account and no subscription. Open the site and you get one empty "Email address" field and a blue "Check" button, with the line beneath that using the site is subject to the terms of use. Type the full address in and hit Check. That is the whole procedure. The public search takes exactly one address at a time, and returns only that address's result.
The scale of what you are searching is worth one line: 1,042 breached sites, 17.8 billion addresses, as of today. The number moves every week. I check my own addresses every few months. My main one has never come back clean, and I have stopped being surprised by that. The surprise would be a clean result after a decade of signups.
Read the result like a report, not a verdict
You get one of two answers. "Good news: no pwnage found!" means the address was not in any breach the site has loaded. "Oh no: pwned! This email address has been found in multiple data breaches. Review the details below to see where your data was exposed." means work. Read it as a list of incidents, one at a time, starting with the worst.
Each breach card carries the same anatomy: the breach name, the date the breach happened, the count of addresses in it, a description of what occurred, and the data classes, the list of field types the dump contained. The data classes are the line that matters most. They say what actually left the building: email addresses, passwords, names, phone numbers, dates of birth. A breach of emails alone and a breach of emails plus passwords are different incidents with different consequences, and the data classes are how you tell them apart.
Below the breaches sits a second section: pastes. These are dumps that surfaced on paste sites rather than in a company's database. HIBP indexes a new paste within about 40 seconds of it appearing and stores the addresses that appeared in the paste plus metadata (the date, the title, the author), never the paste itself. If your address shows up there, read the title: it tells you which dump your address rode in on.
Every breach on your result also has a public catalogue entry. The breached-websites page lists all 1,042 breaches, newest first, with the breach name, the pwn count, the date it was added to HIBP, and the date of the breach itself. Check those two dates against each other: some breaches are loaded within days of happening, others surface years later. An old breach date with a recent added date means the dump circulated privately before it went public. Treat it as fresh, because for the people trading it, it is.
Right now the top reads like a week in October: CyrusOne and Double Counter, both added on 7 October, above Angel One's 6.8 million (added 7 October, breached April 2023) and Medela's 423,900, added 30 September. It is the fastest way to check whether a breach naming you is days old or years old, and how many other addresses went with yours.
What the flags on each breach mean
Every breach carries labels, and the labels change what the result means. Here they are.
What does "verified" mean?
That HIBP did its homework before loading the breach: the impacted service acknowledged it, the data's structure looks like a real breach, there is evidence of the attack vector, and the source has a track record. Most of the big names you will see are verified. It is the default assumption, and the other flags are the exceptions.
What does "unverified" mean?
The dump contains legitimate-looking data, but HIBP could not establish beyond reasonable doubt that it really came from the named service. It is still listed, because it still holds real people's real information. Treat an unverified breach the same as a verified one for your own response: your address is circulating either way.
What about "fabricated"?
This is the odd one. "Fabricated" means HIBP thinks the data almost certainly did not come from the named site; it was likely stitched together from other dumps and sold as something it is not. Your address can be in a fabricated breach for a site you never visited. The name on the card is unreliable; the circulation of your address is not.
Where do sensitive breaches hide?
Eighty-nine breaches are classed as sensitive (the FAQ names Ashley Madison and Adult FriendFinder among them) because mere presence in them is itself the harm. The public search never shows them. Sign in to the dashboard, verify your address through the emailed link, and the sensitive hits appear in the Breaches section under Personal.
What are stealer logs?
Not a website breach at all. Stealer logs come from malware running on infected machines, harvesting the email addresses and passwords people type at login. HIBP indexes the website domains those credentials were used on. If your address turns up through a stealer log, the leak was your device, not a company's server, which means the fix starts with cleaning the machine, not changing a site's password.
What is a spam list?
A dump of personal data (names, addresses, phone numbers, dates of birth) assembled for spam campaigns rather than stolen from one service. It may never have been "breached" in the hacking sense. It is still included, because your data is being redistributed without your knowledge either way. The full FAQ documents every flag in detail.
One more: two breaches, Ticketek and VTech, are retired: permanently removed because the data no longer circulates anywhere. If a breach disappears from your results one day, retirement is the likely reason.
Three things to do for every breach it names
This is my recommended order of operations, not the site's official guidance, applied to each breach on your list in turn:
1. Work out what actually left. Go back to the data classes. If the dump included passwords, assume yours is in it. Emails only? Then the risk is phishing that quotes the breach back at you, not account takeover. The headline names the database. The data classes name the damage.
2. Break the password chain. Change the password on the breached service first, then on every other service where you reused it. The second half is the one people skip, and it is the half attackers count on: credential stuffing, automated login attempts with leaked pairs, is the standard follow-up. Run your password through the Pwned Passwords check while you are at it. It never sees your password: the password is hashed on your own device and only the first 5 characters of the SHA-1 hash are sent; the full comparison happens on your side. If it has been seen before, it should never be used again, and if you have used it anywhere, change it now. A password manager turns this from a weekend into twenty minutes.
3. Cut the future off. Turn on breach notifications: enter the address, click the verification link, and HIBP emails you the moment that address appears in a newly loaded breach. No more manual re-checking. Then fix the structural problem: stop handing every site the same address. One site, one email alias, so the next breach exposes an address that belongs to that site alone and you pause it in one click. Setting one up takes a couple of minutes, and the one-alias-per-site habit is the entire thesis of this blog.
If a stranger emails you your own leaked password and demands money, that is the oldest follow-up scam attached to these dumps. The password is genuine; the threat is empty. Delete it and do not engage.
If the data classes show ID numbers, financial details, or anything beyond credentials, the response escalates past passwords. The FTC's recovery steps are the path: call the fraud departments where fraud occurred, close or freeze the accounts, place a fraud alert, and file an Identity Theft Report.
When the answer is no pwnage found
A clean result means your address was not in any breach HIBP knows about. That is all it means. The site's own line is that absence of evidence is not evidence of absence: a breach has to be found, verified, and loaded before it shows up, and plenty of breaches are never detected at all. Pastes index in about 40 seconds; a fresh corporate breach can take weeks. And the 89 sensitive breaches are invisible to the public search, as above. So a clean result plus notifications switched on is the correct combination: checked once, watched always.
The part the check cannot do for you
No lookup reaches back in time. Have I Been Pwned can tell you where your address has been; it cannot change what you handed out. That is the part only you control, and it is the part this blog exists for. Every site you sign up for tomorrow gets its own alias. When the next breach notice lands, and it will, you read the breach name, pause the one address that site ever had, and move on. The leak-tracing guide shows how the arriving address names its source before you even open the mail, and whether to change your address after a breach answers the question everyone asks at this point. For the full order of operations, keep the breach-response guide bookmarked.
Run the check. Read it like a report. Do the three things, and make the next breach the boring kind: one address, one click, done.
Top comments (0)