Breach checker

What counts as a breach here, and what does not

Our index deliberately restricts itself to incidents with credible public reporting, official company disclosures, regulatory filings, or independent reporting that was later acknowledged. Rumoured dumps without corroboration are excluded, even when they circulate loudly, because acting on unverified claims creates more harm than help.

Each recorded incident stores the discovery window, affected scale, exposed data types and severity, and notes whether passwords, financial data or government IDs were among the compromised fields. That structure is why a domain match is not a generic warning: it points to a named service, a timeframe during which having an account mattered, and a concrete next action.

How to read your result

Address-level intelligence comes first. A clean result there means neither of the live sources currently associates this mailbox with breach datasets they have ingested. It is encouraging but not proof of absence. New aggregations surface continuously and providers have rate limits. A positive result, especially one flagging leaked credentials, means this specific mailbox surfaced somewhere and the password paired with it should be rotated everywhere it was reused, starting with the mailbox itself.

Domain and provider matches come second and are best read as service risk: if you held an account on the listed service around the incident date, assume your record was in the affected set and rotate that service's password even if the address-level check was negative. Prioritize by sensitivity: email, banking and cloud storage before forums and shopping accounts, and revoke active sessions so any live session held by an adversary is terminated.

• Present in breach with leaked credentials: immediate rotation everywhere the password was reused, plus enabling a hardware key or app-based second factor.
• Present at service but without credential flag: rotate the service password and confirm no unknown forwarding or recovery contacts were added.
• No matches in index: maintain unique passwords via a manager and recheck quarterly, since datasets are trailing indicators.

Why both layers matter

Single-layer checkers miss an important asymmetry. Generic domain matching alone over-warns people who never used the affected service. Pure per-address lookups under-warn when the composition of breach lists means a service-level incident is the actionable signal despite a quiet exact-address probe. Combining them with clear labeling gives you both precision where available and coverage where per-address telemetry is unavailable or throttled.

The design also respects privacy: the address is canonicalized and evaluated in memory during the request, a report is built and returned, and nothing is written to disk or access logs beyond the normal operational request metadata that any web server sees. When the widget notes that EmailRep or Gravatar received the address, that is an honest disclosure of the trade required to answer the question at all. Those APIs key by address.

Limitations you should know

No checker can enumerate the dark market comprehensively. Private sales, ransomware negotiations and encrypted forums never surface publicly. Similarly, a negative result does not certify that an account is secure, only that its domain and current live checks did not match the documented corpus at this moment.

Rate limits cause occasional unavailable states for live sources. The report degrades gracefully rather than guessing, and retrying usually restores the signal. For the most sensitive accounts, supplement this check with the provider's own Have I Been Pwned-style notifications and with monitoring inside the services themselves.