Revealer returns evidence that an identifier exists somewhere and where that evidence came from. It does not return raw credentials, and it is not a consumer reporting agency, so its results cannot lawfully be used for hiring, tenancy, credit, or insurance decisions. Breach and stealer-log material is fenced: we confirm that an identifier appears in a named corpus and describe what class of data that record held, without handing back the sensitive contents. Public-records and open-web material is returned directly with its source attached. Everything on the platform is subject to opt-out.
That paragraph is the short version. What a tool refuses to do is usually more informative than its feature list, and vague sourcing claims are the norm in this industry. The rest covers what the source count actually counts, the three data classes and how each is treated, the specific things we will not return, and where the legal line sits.
What "800+ sources" actually means
Source counts in this market are marketing numbers, and they are almost never defined. Here is our definition, so you can discount ours appropriately.
A "source" is a distinct connector — one queryable surface with its own access method, response format, and failure mode. That includes public-records providers, open-web platform surfaces we check directly, structured directories, registration and business filings, and individually named breach and infostealer corpora.
Three qualifications matter more than the number:
Not every source fires on every query. Connectors are selected by identifier type and jurisdiction. A username query does not touch phone-carrier data. A UK address query does not touch US county records. A typical search meaningfully consults a small fraction of the catalogue. Anyone implying that every query hits every source is describing something that would be slow, expensive, and mostly noise.
Corpora are counted individually, and that inflates any count. A single leak incident may be distributed as several dumps with different schemas. Counted as connectors, that is several sources. This is the standard reason source counts across the industry are not comparable — every vendor draws the boundary differently, and none of them publish the rule. Treat any raw count, ours included, as a rough indicator of breadth rather than a quality measure.
Coverage is uneven and always will be. US public-records depth is far better than most other jurisdictions. Recent identifiers resolve better than dormant ones. Landline and long-held mobile numbers resolve better than VoIP and freshly issued SIMs. The honest read on a null result is "not found in the sources consulted," never "does not exist."
The three data classes, and how each is handled
Public records and open-web material
Voter files, property and assessor records, court and lien filings, business registrations, licensing bodies, and publicly visible platform profiles. This is lawfully accessible material and it is returned directly, with its source identified so you can go to the original record. Depth varies by state and county; some jurisdictions publish generously and some publish almost nothing, which is why two searches that look similar can return very different amounts.
Be careful about aggregation here. Each individual record may be innocuous, and the combined profile can still be sensitive. That is a real property of this category, not a disclaimer, and it is why we gate access behind account authentication and log usage.
Platform-surface checks
Live checks against public profile surfaces — whether a handle resolves, what the public profile exposes. These are performed against publicly reachable pages only. We do not authenticate into platforms, scrape behind logins, bypass access controls, or use credentials to reach private content. If a platform gates something, it stays gated. This is also why username search results can miss real accounts: a gated or region-blocked profile is invisible to an anonymous request, and we would rather report that honestly than guess.
Breach and stealer-log corpora
This is the category with the tightest fence, on purpose.
For breach data, a data breach lookup confirms whether an identifier appears in a known corpus, names the incident where it is known, indicates the approximate date, and describes the classes of data that record contained — email, hashed password, phone, physical address, and so on. That is exposure intelligence: enough to tell someone what to rotate and what to watch, without redistributing the leak.
Infostealer material is handled more tightly still. Stealer logs come from malware that harvested a victim's browser: saved credentials, session cookies, autofill, sometimes system fingerprints. The security-relevant fact is that a device was compromised and which services appeared in that log, which is exactly what a defender needs in order to force password resets, revoke sessions, and check for follow-on account access. The contents themselves are the attacker's payload, and we do not hand them over.
What we will not return
By design we do not return:
- Plaintext passwords, password hashes, or anything a credential-stuffing operation could use. We report that a credential class was exposed for an identifier. We do not return the credential.
- Session cookies, tokens, or authentication artifacts from stealer logs. Returning these is handing over live account access. There is no legitimate research use that requires the raw token rather than the fact of the compromise.
- Full financial identifiers. Complete card numbers, bank account numbers, and government identifiers such as full SSNs are not returned, even where a source record contains them.
- FCRA-covered eligibility determinations. We do not produce consumer reports, credit files, or screening decisions. No scoring for hiring, tenancy, lending, or insurance. This is not merely a policy preference; it is a statutory boundary described below.
- Data on minors, as a targeted search. Minors are not a supported search subject.
- Real-time location or covert tracking. No live device location, no GPS, no continuous monitoring of an individual's movements.
- Anything requiring pretexting, unauthorized access, or platform-ToS violation to obtain. No logging into accounts, no impersonation, no bypassing access controls, no purchasing access that was obtained through account takeover.
- Bulk export of an entire data class. Access is scoped to searching for identifiers, not to downloading the underlying corpora. Plan limits on pricing are per-search and per-period for exactly this reason.
If a use case only works with one of the items above, we are not the right vendor, and no amount of plan upgrade changes that.
The FCRA boundary, in practical terms
Revealer is not a consumer reporting agency, and its data is not a consumer report as defined by the Fair Credit Reporting Act. You may not use it to make or inform decisions about:
- employment, including hiring, promotion, retention, or contractor engagement
- tenant screening or housing eligibility
- credit or lending eligibility
- insurance underwriting or eligibility
- any other purpose defined as a permissible purpose under the FCRA
The reason is structural, not procedural. The FCRA imposes obligations a search tool cannot satisfy by adding a checkbox: accuracy procedures, adverse-action notice, and a dispute-and-correction process that gives the subject a route to fix a wrong record before it costs them a job or an apartment. Those protections exist because the consequences of being wrong in that context are severe. Running a general-purpose search and treating the output as a screening report strips them out.
Lawful uses are broad: fraud investigation and prevention, identity verification, security research and incident response, journalism, due diligence, skip tracing within legal limits, reconnecting with people, checking your own exposure, and authorized casework. What separates them from the prohibited list is that none of them are statutory eligibility determinations about a consumer.
The same principle blocks harassment, stalking, doxxing, and intimidation, which are prohibited regardless of legal framing.
Null results, staleness, and other honest limits
A few things other vendors gloss over:
A null result is not proof of absence. It means the consulted sources had nothing for that identifier. Coverage gaps, recency, and jurisdiction all produce empty results for people who very much exist.
Records go stale. Public records update on their own schedules — sometimes weeks, sometimes years. An address that was accurate at filing may be years out of date. Anything time-sensitive should be verified at the primary source.
Records can be wrong. Data-entry errors, name collisions, and merged records happen upstream and propagate. Two people with the same name in the same metro area are a recurring failure mode across the entire industry. Treat any single record as a lead requiring corroboration, not as an established fact.
Breach attribution is imperfect. Some corpora circulate without reliable provenance, are recombinations of earlier leaks, or carry disputed attribution. Where an incident is uncertain, that uncertainty belongs in the result rather than being smoothed away.
Opt-out
Anyone can request removal of their information from Revealer's people-search results through the opt-out page. We honor requests regardless of where the person is located or whether their jurisdiction requires it.
Two things to understand about scope. First, opt-out removes you from our results; it does not delete the underlying public records, which live with the county, court, or agency that published them, nor does it reach other data brokers. Second, breach-exposure lookups on your own identifiers are a security function — knowing you appear in a leak is how you know to rotate a password — and that is a different thing from a searchable people-search profile.
If you are checking your own footprint rather than someone else's, the useful order is: run your own identifiers through breach lookup first to see what is already exposed, then decide what to remove.
Frequently asked questions
Does Revealer sell or return raw breach data? No. Breach results confirm that an identifier appears in a known corpus and describe what classes of data that record contained. Passwords, hashes, session cookies, and other directly exploitable contents are not returned, and the underlying corpora are not available for bulk export.
Can I use Revealer to screen a job applicant or tenant? No. Revealer is not a consumer reporting agency and its results are not consumer reports. Employment, tenant, credit, and insurance decisions require an FCRA-compliant provider that offers accuracy procedures, adverse-action notice, and a dispute process. Using general-purpose search data for those decisions removes protections the subject is entitled to.
Why did my search return nothing? Most often because the consulted sources have no record for that identifier — thin coverage in that jurisdiction, a recently issued number, a rarely used handle, or a dormant identifier. It can also mean the identifier is real but only visible behind a login or a region block. A null result means "not found in the sources consulted," not "does not exist."
What does "800+ sources" mean in practice? It counts distinct connectors: public-records providers, platform surfaces, directories, and individually named breach corpora. Only the connectors relevant to your identifier type and jurisdiction run on any given query, so a single search consults a small subset. Source counts are not comparable across vendors because nobody defines the boundary the same way.
How is stealer-log data different from breach data? Breach data comes from a compromised service and typically exposes the records that service held. Stealer-log data comes from malware on an individual's device and reflects whatever that browser had saved. Stealer-log exposure usually implies a broader compromise, which is why it is treated as an incident-response signal and why its contents are fenced rather than returned.
How do I get my information removed? Submit a request through the opt-out page. Removal applies to Revealer's people-search results. It does not delete the source records held by government agencies or other publishers, and it does not affect other data brokers, which have to be contacted separately.