How XposedOrNot Works: Dataset Methodology

776 indexed data breaches. More than 11.5 billion exposed records. Last reviewed: August 15, 2026.

This page documents exactly how data enters the XposedOrNot database, how it is verified, and what the numbers mean, so researchers, journalists, and security teams can cite XposedOrNot with confidence. Everything described here is verifiable: the platform is fully open source, and the same data is available through the free API.

Where the data comes from

XposedOrNot indexes breach data that is already publicly available on the internet. Breach datasets typically circulate on various websites and, in some cases, through technologies such as torrents. XposedOrNot only uses data breaches that have been made publicly available, and relies substantially on the security research community and public disclosures.

The complete list of indexed breaches is public and browsable on the Xposed breaches page, and every breach entry names its source incident with a reference.

What qualifies for indexing

Whether a breach is included is decided against a public-interest standard:

• Reliable source verification: is the breach authentic and verified?
• Substantial impact on individuals: does it affect a significant number of people?
• No ongoing risk: will disclosure cause harm or create safety issues?

If disclosing a breach could cause harm or violates a legal restriction, that dataset is excluded or limited. Breaches involving sensitive services are additionally marked so they cannot be searched publicly (see tags below).

How breaches are verified

Every breach indexed by XposedOrNot is verified through acknowledgment by the affected website owner or coverage by online media, and each breach entry carries a reference. Verification of individual data breaches is currently a manual process, done with utmost care to ensure accuracy.

In rare cases where a breach is not acknowledged by the website owner, it is marked as such, and the affected organization is notified through defined processes. Such communication is posted publicly on the XposedOrNot Twitter account and in the breach references.

Breach tags

As of August 2026, 742 of the 776 indexed breaches carry the Verified tag. The rest are marked accordingly rather than presented as confirmed.

Breach types

Each entry also carries a type, so incidents of different natures are never mixed together. As of August 2026 the 776 indexed breaches break down as:

Two dates for every breach

Every breach entry carries two distinct dates, exposed in the API as separate fields:

• Breach date (breachedDate): when the breach occurred.
• Added to XON (addedDate): when the breach entered the XposedOrNot index.

What record counts mean

Each breach carries an exposed-records count: the number of records in the leaked dataset as indexed. The totals shown on the repository statistics page are the sum of these per-breach counts. Two caveats matter for anyone citing the numbers:

• Record counts are inherited from the leaked dataset, which may be partial or contain inaccuracies from the original source.
• The same email address can appear in many breaches, so record totals count exposures, not unique individuals.

Compilations and repackaged data

Credential-stuffing compilations such as Collection-1 are indexed as their own entries and labeled with the ComboList type, never merged into the original incidents they may draw from. This keeps single-incident breaches distinguishable from aggregated compilations, both in search results and in any statistics built on the data.

Stealer logs

Infostealer malware captures browser-saved passwords, session cookies, autofill data, and crypto wallets from infected devices. XposedOrNot indexes this stealer-log data, labels it with the StealerLogs type, and includes it free of charge in every email search, domain scan, and dashboard. Many breach-monitoring services gate stealer-log access behind paid plans; XposedOrNot does not.

What is stored, and what is never stored

XposedOrNot never republishes or distributes complete breach dumps. From each breach dataset:

• Stored: email addresses, extracted from the dataset to power search.
• Stored: public breach metadata: breach name, date, affected organization, industry, and the general categories of data exposed.
• Never stored: plaintext passwords, credit card numbers, social security numbers, personal identification documents, or any other sensitive personal data from the original breach.

The password checker is built on more than 835 million exposed passwords stored exclusively as one-way Keccak-512 (SHA-3) hashes, and only a partial hash of your input is ever transmitted when you check one. All storage and processing happens in isolated cloud environments with encryption at rest and in transit, and raw personal data is never shared, sold, or provided to third parties. Full details are in the Transparency Report.

How risk scores are calculated

Each email's breach exposure is summarized as a weighted risk score from 0 to 100. Every exposed data type is assigned to a risk tier (critical types such as passwords and bank details score 10 points, high 7, medium 4, low 1), the points are summed across the email's breaches, and the raw score is adjusted by modifiers for breach recency and password-exposure severity. The full formula, including every data type per tier, is documented in the FAQ.

Corrections, takedowns, and updates

The database is updated continuously as new breaches are discovered and verified; the most recent addition is always visible on the repository statistics page. Found an error in a breach entry? Contact deva@xposedornot.com and it will be reviewed.

Takedown and legal requests are each reviewed against legal standards before action is taken. When a breach dataset becomes subject to a court injunction or valid takedown request, it may be suppressed or geo-limited. Statistics on all such requests are published quarterly in the Transparency Report; through 2026 Q2, zero takedown requests have been received.

Limitations

Honest limits matter more than big numbers. XposedOrNot's coverage has these:

• Only breaches that have been publicly disclosed, or received through our sources, can be indexed. Many breaches remain unreported, undiscovered, or confidential under legal agreements.
• Breach data may be incomplete or contain inaccuracies inherited from the original source, including record counts.
• Coverage relies substantially on the security research community and public disclosures.
• A search showing no breaches does not guarantee an address has never been compromised.
• Verification is a manual process; in rare cases a breach may be indexed before the affected organization acknowledges it, and it is marked accordingly.

Privacy of searches

Search queries are processed in memory and never logged in any identifiable form; the email addresses people search for are not stored, sold, or used for marketing. Queries are not associated with IP addresses beyond transient security logs that are automatically purged. The only exception is the opt-in AlertMe service, which stores a confirmed email address (dual opt-in) so it can notify the owner about future breaches. Anyone can also use Privacy Shield to permanently mask their address from all public search.

For researchers and journalists

• Aggregate statistics, updated live: xposedornot.com/our-repository
• Full breach index: xposedornot.com/xposed
• Programmatic access: free API and MCP server
• Questions about the data: deva@xposedornot.com

Suggested citation:

Who maintains this