How to check if your information has been leaked
Four different things get called a leak and each one needs a different response. Where to check for free, how to read a match, and why a device capture means more than a leaked password.
Almost any email address that has been through fifteen years of the internet is somewhere it was not meant to be. That fact on its own is not useful. What matters is which of four different things happened, because they carry different amounts of risk and call for different responses, and the gap between the mildest and the most serious is not a matter of degree. This is how to check each one, starting with tools that cost nothing, and how to read what comes back.
"Leaked" covers four different situations
The word gets used for all four interchangeably, which is why so much advice about it is useless. Separating them makes everything afterwards easier.
A credential record from a compromised service
A company was breached and the table of its users was taken: email addresses, usernames, password hashes or sometimes plaintext, phone numbers, whatever that service happened to store. One row of that table is one account at one service at one moment. This is the oldest and most common kind of exposure, and by itself the most contained.
A capture from a compromised device
Malware ran on somebody's computer, made one sweep, and copied what the browser was holding: saved logins for every site, session cookies, autofill entries, saved cards, sometimes cryptocurrency wallet files, plus a fingerprint of the machine. The bundle it writes is called a stealer log. The unit of exposure here is not an account, it is a person and a machine. There is a longer piece on how that supply chain works in stealer logs are the easiest path to a data breach.
A public social footprint
No breach is involved. One username reused across a decade of forums, marketplaces and social platforms ties together accounts their owner assumed were unrelated. Every profile is readable by anyone. What turns it into exposure is that anyone can also collect all of it at once and read it as a single picture.
Public records that were never private
In the United States a great deal is filed publicly by design: property deeds, voter registrations, court and bankruptcy filings, professional licences, business registrations, decades of address and telephone directories. Data brokers assemble those filings into profiles and sell the result. Nothing was stolen. The information was public the day it was created, which is why "leaked" is the wrong word for it and why almost none of the standard advice applies.
Where to check, free options first
Have I Been Pwned
Have I Been Pwned is free, searchable by email address or username, and the reasonable first stop for the credential-record question. It also runs a free notification service that mails an address when it next turns up.
Three details are worth knowing before reading its answers. Breaches marked sensitive are only visible after verifying that you can receive mail at the address being searched, and searching an entire domain requires proving authority over that domain. It now indexes stealer logs too, storing the website domains that credentials were entered against, reachable through the notification service and a dedicated API rather than the public search box. And some material traded as a breach is aggregated from elsewhere or fabricated outright, which is why records carry unverified and fabricated flags instead of being silently dropped.
To test a specific password rather than an address, Pwned Passwords reports whether that password has appeared in a breach corpus without ever receiving it. The password is hashed locally, only the first five characters of the hash are sent, and the comparison finishes on your own machine.
The password manager and browser already installed
Several first-party checks are already sitting on most people's devices, switched on or one toggle away.
- Chrome's Google Password Manager has a Checkup that encrypts saved credentials and compares them against an encrypted list of known breached data, plus a setting to warn when a saved password is exposed later.
- Apple marks saved passwords as reused, weak, or leaked via Password Monitoring, surfaced under Security Recommendations.
- Firefox's password manager warns about saved logins for sites it knows were breached.
- Bitwarden's Data Breach report is free on every account and built on Have I Been Pwned data, while most of its other vault health reports are premium.
- 1Password's Watchtower alerts paying users about breached sites and weak or reused credentials.
- Mozilla Monitor scans up to twenty addresses free, against publicly available breaches going back to 2007.
One tool people still go looking for is gone. Google retired its Dark Web Report, stopping new scans on 15 January 2026 and removing the feature on 16 February 2026, on the stated grounds that feedback showed it did not provide helpful next steps.
A social footprint
There is no directory of who holds an account where, so the only way to establish whether a handle exists on a platform is to ask that platform. Search engines cover the part that is indexed. Reaching the rest means resolving the handle site by site, which is what the social accounts surface here does at scale.
Public records
Searching a name on the large people-search sites shows roughly what a broker holds. Removal is a separate process from searching, and it is normally per broker. Californians have one central option: DROP sends a single deletion request to every data broker registered in the state. It opened to residents on 1 January 2026, and brokers begin processing requests on 1 August 2026.
Reading a result
A match is evidence that an identifier was exposed at least once. That is the whole claim. It is not proof that a password still works, and it is not proof of which company lost it: compilations frequently name no origin at all, and a source label describes where a row was recovered from rather than where it originally came from.
Two further cautions. A username belongs to more than one person, so a hit against a service someone never used is often just another person who liked the same handle. And an email address can legitimately appear against a service its owner never signed up to, for ordinary reasons including one business acquiring another's data or rebranding.
Why the same address comes back over and over
Almost nothing in this market arrives clean. Dumps are merged with other dumps, deduplicated, split, renamed and resold, so one row can appear in a dozen compilations under a dozen names. Counting hits therefore measures how much repackaging has happened, not how exposed a person is.
The useful reading is spread. Distinct sources with distinct dates mean distinct events. Fifty results dated the same month, carrying the same field for the same address, are more likely one event wearing fifty coats. Age matters for the same reason: a password abandoned in 2013 is a historical footnote, while the same password still in use somewhere is a live account.
A breach row and a device capture are not the same problem
This is the distinction most guidance skips, and it changes everything downstream.
A breach row means one service held a credential and lost it. The response is bounded. Change that password, change it anywhere it was reused, and the matter is closed.
A device capture means the browser's entire credential store left the machine in one pass, along with live session cookies. A session cookie is used after login, so replaying it walks past the password and the second factor together. Google's own description of the problem is that cookie theft happens after login, and therefore bypasses two-factor authentication and any other login-time check. Against that, changing one password fixes one line of a large file.
One more property of device records: their dates are collection dates, meaning when an archive was posted and when it was indexed, not infection dates. Nothing in the material says when a machine was actually swept, so a capture published last week can be a year old.
What to do, in order
Give every account a password it shares with nothing else
Reuse is the vulnerability that turns one company's bad week into somebody's account takeover, and a password manager is the only practical way to hold a few hundred unique passwords. NIST's current guidance is worth borrowing personally: new passwords should be compared against a blocklist of known compromised ones, periodic rotation should not be forced, and a change should be forced on evidence of compromise. Rotate on evidence, not on the calendar, and treat a password found in any breach corpus as evidence.
Revoke sessions, not just passwords
Rotating a password does not necessarily end the sessions already open. Google documents that a password change signs you out everywhere except devices used to verify sign-ins, some devices running third-party apps that were granted account access, and home devices given access. Sessions are actually terminated from the account's device list. Most major services have an equivalent screen. Use it after the password change rather than instead of it.
Put phishing-resistant second factors on the accounts that matter
CISA ranks MFA forms from strongest to weakest in its phishing-resistant MFA fact sheet. FIDO/WebAuthn authenticators, meaning security keys and passkeys, and PKI-based smart cards resist phishing. App-generated one-time codes do not resist phishing, though they do resist push bombing. SMS and voice are described as a last resort, being exposed to phishing, SS7 interception and SIM swapping. Any second factor beats none. Start with the email account, because email recovers everything else.
Decide whether the machine can still be trusted
When the evidence points at a device capture rather than a service breach, the machine is the problem and cleaning is the weaker option. The UK's NCSC advises a factory reset for a compromised device, and makes the point that rescuing data off a still-infected machine risks carrying the infection through the rebuild. Its malware guidance adds the rest of the sequence: disconnect from every network, wipe the device and reinstall the operating system, connect to a clean network to update it, verify a backup is clean before restoring it, and reset credentials. Doing that rotation from the infected machine is the common mistake, since the replacement password is captured exactly the way the original was.
What monitoring does and does not do
A standing monitor answers one narrow question: has this identifier appeared somewhere new since the last check. The Have I Been Pwned notification service does that free for a verified address, Mozilla Monitor does it for up to twenty, and monitors here watch a single asset or an entire domain and report the next appearance. The value is timing. The gap between a credential being published and being used is the window in which any response happens at all.
What no monitor does is remove anything. Notification is not deletion. Data that has been copied, merged and resold cannot be recalled, and any service implying otherwise is selling reassurance. Broker deletion requests are the one real exception, and they apply to the public-records surface only, not to breach corpora and not to device captures.
A clean result is weaker evidence than it looks
Have I Been Pwned states the limit of its own answer plainly: absence of evidence is not evidence of absence. Any index holds a subset of what has been breached, many breaches never result in a public release, and some are never detected at all. A clean search means an identifier was not found in what was searched, which is a smaller claim than it feels like.
So the ordinary work matters more than the searching. Unique passwords everywhere, phishing-resistant second factors on the accounts that recover the others, sessions revoked when something turns up, and one clear-headed decision about whether a given machine can be trusted. Checking tells you where you already stand. It does not move you.