Leak Search: how to check if your info has been leaked

At some point almost everyone's data ends up somewhere it shouldn't. A site you signed up for in 2015 gets breached. A family laptop picks up malware. An old password you still reuse surfaces in a dump traded on a forum. The question is not usually whether any of your information has leaked. It is what leaked, how recent it is, and what an attacker can actually do with it.

This guide walks through how to check, using the free leak search, how to read the results, and what to do if your information shows up. It takes about ten minutes to do properly.

Two kinds of exposure, and why the difference matters

Before you search, it helps to know what you are looking for. Leaked data tends to come from one of two places, and they are not equally dangerous.

The first is the classic database breach: a company gets hacked, and the table of its users (emails, usernames, hashed or sometimes plaintext passwords, phone numbers) ends up traded online. This is what most "have I been breached" tools were built to find. It matters, but a single old password hash from one site is a fairly contained problem.

The second is a stealer log, and it is a different animal. When an infostealer infects a computer, it does not take one password from one site. It takes everything the browser ever saved in cleartext: every login, every live session cookie, autofill data, sometimes credit cards and crypto wallets, plus a snapshot of the machine itself. If you appear in a recent stealer log, the assumption is not "one password leaked." It is "every credential that browser remembered is in someone else's hands." We wrote about why that shift matters in Stealer logs are the easiest path to a data breach .

A breached password is a lock you need to change. A stealer log is someone who copied your whole keyring, including the keys you forgot you had.

Step 1: Search your primary email

Start with the email address you use most. Open the search page, choose Email as the search type, enter the address, and run it.

What comes back is a list of the sources that contain that address. Each result tells you which dataset it came from and which fields were exposed alongside your email: a username, a password (plaintext or hashed), a phone number, a name, an IP address. Read the exposed fields carefully, because that is the difference between "they know I had an account somewhere" and "they have my reused password."

Step 2: Search more than just your email

One email address is a narrow view. Attackers do not search the way you do; they pivot across every identifier they can find. You should too. The search supports several types beyond email:

• Username. The handle you reuse across forums, gaming sites, and social accounts often links identities that you thought were separate.
• Phone number. Increasingly the pivot point for SIM-swap and account-recovery attacks, and present in many recent dumps.
• Password. You can check a specific plaintext password to see whether it already appears in known data. If it does, treat it as burned everywhere you used it.
• Full name, IP address, or hash. Useful for confirming whether a particular record is really you, or for investigators tracing a specific artefact.

Run your main email first, then your secondary and old addresses, then the usernames and phone numbers tied to them. Each search is a different doorway into the same picture.

Step 3: Read the results like an attacker would

Finding your email in a ten-year-old forum dump is mildly interesting. Finding it in a stealer log from last month is an emergency. When you look at a result, weigh three things:

• How recent is it? Recency is everything. Session cookies and tokens in a fresh stealer log may still be valid right now. A password from 2014 that you have since changed is mostly a historical footnote.
• What fields are exposed? An email on its own is low risk. An email next to a plaintext password you still use is a live account takeover waiting to happen.
• Is it a database dump or a stealer log? A dump exposes what one site held about you. A stealer log exposes what your browser held about every site, which puts far more at risk.

Step 4: What to do if you show up

Do not panic, but do act in order of impact. If you appear in a database breach with an exposed password:

• Change that password everywhere you used it, starting with email and banking. Reuse is the real vulnerability, not the single breach.
• Turn on two-factor authentication, preferably an authenticator app or hardware key rather than SMS.
• Move to a password manager so every account gets a unique password and the next breach stays contained to one site.

If you appear in a stealer log, the cleanup is more aggressive, because a password change alone does not help when the attacker also has your session cookies:

• Treat the infected machine as compromised. Run a full malware scan, and if in doubt, reinstall the operating system before trusting it again.
• Rotate passwords for every account that browser had saved, not just the obvious ones.
• Revoke active sessions on your important accounts (most services have a "sign out of all devices" option). A stolen session cookie keeps working until the session is invalidated, even after you change the password.
• Clear and re-key anything sensitive the browser stored: saved cards, autofill, and especially any passwords kept in the browser's own vault.

Step 5: Stay ahead of the next leak

Checking once tells you about the past. The leaks that hurt are the ones you find out about months too late, when someone has already used the credential. The fix is to watch your identifiers continuously instead of searching them by hand.

Set up a monitor on your email addresses (and any domain you own). When one of them turns up in a new dump or stealer log, you get notified that week, not when your bank calls. For an individual, that head start is usually the entire difference between a quick password rotation and a drained account.

If you are checking on behalf of a business

The same workflow scales. Instead of searching one address at a time, use bulk search to audit your entire workforce in a single query, stand up monitors on every corporate and vendor domain you depend on, and pull matches straight into your own tooling through the API. The goal is the same as for an individual, just wider: catch the exposure during the window between when a credential leaks and when an attacker gets around to using it.

The short version

• Search your email, then your usernames, phone numbers, and any password you suspect, in the leak search.
• Judge each result by recency, the fields exposed, and whether it is a database dump or a stealer log.
• For breaches, fix password reuse and turn on 2FA. For stealer logs, clean the machine and revoke sessions, not just passwords.
• Put a monitor on your addresses so you hear about the next leak first.

You cannot un-leak data that is already out there. What you can control is how fast you find out and how quickly you close the door. Ten minutes of searching now, and a monitor that watches for you afterward, is most of the battle.