LeakCheck vs HaveIBeenPwned looks like a choice between two breach databases, and it is really a choice between two questions. HaveIBeenPwned (HIBP) answers "which breaches contain this email?" LeakCheck answers "what did those breaches contain next to it?" One is a notification service built for the people who were breached. The other is a record-level search built for people investigating exposure. They overlap on the list of breaches and diverge on almost everything after that.
This post compares scope, access, what each returns, cost and the ethical weight of record-level data. It closes with how OSINTsearch ladders breach disclosure across its plans, because the tiering is a direct answer to the question of who should see what.
What HaveIBeenPwned returns
HIBP, run by Troy Hunt, indexes breach datasets and lets anyone check whether an email address or phone number appears in them. The response is a list of breach names with dates, record counts and the data classes each one exposed: email addresses, passwords, usernames, IP addresses and so on. It never shows you the actual username or password from the record. The Pwned Passwords service lets you check a password hash against known-leaked passwords using k-anonymity, again without revealing anything else.
curl -s -H "hibp-api-key: $HIBP_KEY" \
"https://haveibeenpwned.com/api/v3/breachedaccount/user%40example.com?truncateResponse=false" \
| jq '.[] | {Name, BreachDate, DataClasses}'Domain search lets a verified domain owner see all addresses on that domain that appear in breaches. That is the closest HIBP gets to a bulk investigative feature, and it is deliberately limited to owners. The API requires a paid key; the website is free for single lookups.
What LeakCheck returns
LeakCheck is a paid service that indexes breach and compilation data and returns the records themselves: for a query email, the username, name, phone, date of birth, address or IP that sat in the same row, along with the source name and date. Queries can be by email, username, phone, name or other keys, and the public API is used by a lot of investigative tooling, including OSINTsearch.
The record is the point, and it is also the hazard. A username paired with an email in a 2017 gaming forum dump is a pivot that turns one identifier into a 750-platform sweep. A home address paired with a name is something you have no business seeing without a lawful reason. LeakCheck sells access with terms; the responsibility for what you do with a record sits with you.
| HaveIBeenPwned | LeakCheck | |
|---|---|---|
| Question answered | Which breaches include this identifier | What the breach records contain |
| Query keys | Email, phone, domain (owner-verified) | Email, username, phone, name, keyword, others |
| Returns identifiers of other people | No | Yes, from the same record |
| Passwords | Never in lookups; hash check via k-anonymity | Present in the source data; OSINTsearch strips them at fetch |
| Access | Free site, paid API key | Paid plans and API |
| Best for | Notifying and protecting the affected person | Investigating exposure and pivoting |
Where they agree and where they differ in practice
Both will tell you an address is in a known breach and roughly when. HIBP's breach list is carefully curated; LeakCheck includes compilations, which are aggregated dumps with uncertain provenance, and marks them. If you only need "has this address been exposed, and should I rotate?", HIBP is the right tool, and it costs nothing.
If your work is identity resolution, HIBP stops one step short. The data class "usernames" tells you a handle exists in the record; it does not tell you what the handle is. LeakCheck does, and that handle is often an old one, which is exactly the kind of lead that finding old usernames depends on. In my own cases the breach-recovered handle has been the link between two profiles more often than any other single field.
How OSINTsearch tiers breach disclosure
OSINTsearch uses LeakCheck upstream, and the disclosure ladder has three rungs, chosen so that the cheapest tier cannot spend the shared query budget and the middle tier cannot see identifiers. It is a cost control and a privacy control in the same table.
- Free: none. The breach API is not called. The route refuses before any upstream contact and before quota is consumed. The upstream limit is 13 requests per second charged to the whole account, shared by every visitor, so unbounded free traffic would starve the paying tiers.
- Starter: partial. The lookup runs. You see which breach, when, the exposed data categories, and counts of how many records carry a username, email, phone, name, date of birth, address or IP. No value is shown, not even a masked one, because those are other people's identifiers rather than the one you typed.
- Pro and Enterprise: full. The projected record as the upstream returns it, with passwords and government id numbers stripped at the fetch boundary for every tier. There is no plan on which a plaintext secret exists to be shown.
{
"source": { "name": "ExampleForum", "breachDate": "2019-03", "compilation": false },
"exposed": ["email", "username", "password"],
"passwordExposed": true,
"has_username": true,
"has_phone": false,
"_disclosure": "partial"
}The partial rung withholds rather than masks on purpose. A first character plus a length class is a fair teaser for a social result, because it proves the account you searched for exists on a platform you named. Inside a breach corpus the values belong to other people, and narrowing their name space without being asked to is not a teaser, it is a leak. The Pro rung also feeds handles discovered in breach records into deep search as seeds, so a username from a 2019 dump can be swept across the live platforms in the same session. Plans are on the pricing page; the username search is free to try.
LeakCheck vs HaveIBeenPwned: choosing between them
Use HIBP when you are the affected party, or advising one: it is free, careful, and built for exactly that. Use LeakCheck, directly or through a tool that tiers access, when you are resolving identity and need the paired fields, and hold yourself to the retention and purpose limits that come with record-level data. The two are complementary far more often than they are rivals, and the email OSINT guide shows where breach lookups sit in a wider sequence.
FAQ
Is LeakCheck legal to use?
Access is sold under terms and is lawful in many jurisdictions for security research and authorized investigation. What makes a specific query lawful is your purpose and basis, not the service.
Does HaveIBeenPwned show passwords or usernames?
No. It lists breach names and data classes. Pwned Passwords checks a hash prefix against leaked passwords without revealing any record.
Does OSINTsearch show passwords from breaches?
No. Passwords and government id numbers are removed at the fetch boundary on every plan, including Pro and Enterprise.
Why does Starter show counts but not the handles?
Because the handles are other people's identifiers sitting in the same record. Starter shows which breach and how many records carry each field type; Pro shows the projected records.
Different questions, different duties
LeakCheck vs HaveIBeenPwned is not a benchmark contest. HIBP tells someone they were exposed; LeakCheck tells an investigator what the exposure contained. The second is more powerful and carries more duty, which is why the sensible design is not to hide it but to tier it, log it, and strip the fields that nobody has a legitimate reason to read.
