Our OSINT Data Sources & Coverage

A useful OSINT result begins with a simple question: which source produced it, what exactly was checked, and how current is that answer? This page answers those questions for SpiderFoot.tools from the public application code and its deployed configuration—not from a marketing estimate. It is a coverage map, not a promise that every account, person, or data point can be found.

Quick answer: where do SpiderFoot.tools results come from?

Today, the public interface is configured for three input types: usernames, email addresses, and IP addresses. Each follows a different route. Username checks use a local set of public-profile definitions through a configured worker, a separate category-based scan API, and—when enabled and allowed for the request—a web-search integration. Email checks use the separate scan API and the same optional web-search integration. Submitted IP addresses use Cloudflare Radar IP details; a blank IP lookup instead reads the visitor information available on the current Cloudflare-backed request.

That means “coverage” is not one giant database. It is a combination of maintained check definitions, live or provider-dependent requests, short-lived and longer-lived application caches, and UI rules that turn upstream responses into labels. A result is evidence to assess, not an identity decision. For the practical safety boundaries around this kind of research, see Is SpiderFoot Safe to Use?.

Current coverage snapshot

The figures below are programmatically derived from the active project configuration and the local username-definition dataset. They measure what is configured to be queried; they do not measure accuracy, uptime, recall, the number of people indexed, or geographic completeness.

What “supported platform” means—and what it does not

A username platform is supported when the application has a usable public check definition for it: for example, a public profile route or a documented response rule that the configured checking path can evaluate. The local definition dataset contains 708 active definitions in 21 categories. The largest category is social (210 definitions), followed by gaming (76), hobby (50), coding (47), and technology (43). These are configuration counts, not a count of separate companies, available endpoints, users, or verified profiles.

The definition file also has four language-tagged Chinese definitions and 704 unrestricted definitions. The browser can filter language-tagged entries against the visitor’s browser-language list, so the exact set attempted in one session can vary by locale. Definitions need maintenance: sites change URLs, return interstitial pages, add rate limits, or make similar responses look different. Maintained projects such as WhatsMyName, Sherlock, and Maigret document why response classification and regular testing matter.

We therefore do not describe this file as a harvested profile database. It is a maintained collection of public-check routes. A definition can be present while its current route is unavailable, blocked, changed, or ambiguous; conversely, the absence of a definition does not establish that a platform has no public profile page.

The query path, step by step

Username

A username search can combine three evidence paths. First, the browser loads the local profile-definition dataset and sends appropriate checks through the configured worker. Second, it asks a separate scan API for the 13 configured categories: social, gaming, music, creator, community, shopping, development, donation, email, finance, other, political, and adult. Third, when the setting is enabled and the requesting country is allowed, the server can request Google organic results through Serper. The project’s current source does not name the upstream providers behind the separate scan API, so this page does not infer or list them.

Email address

The email flow calls the separate scan API with 18 categories: social, music, gaming, jobs, news, shopping, sports, learning, development, adult, community, creator, CRM, entertainment, fitness, hosting, other, and travel. It can also use the Serper-backed organic-search route under the same enabled and regional conditions. The public source reviewed for this snapshot does not name or enumerate an upstream email-data provider. In particular, this page makes no claim of breach-database coverage. It does not provide passwords, private mailbox content, credentials, or access to non-public accounts. Read the scope and consent discussion in Is Email OSINT Legal? before using any identifier that is not yours or not within an authorized investigation.

IP address

For a submitted, valid IPv4 or IPv6 address, the server requests Cloudflare Radar IP details. The returned context can include network and location-related fields such as ASN details, organization naming, and approximate location, depending on the provider response. This is network context, not proof that a particular person controls an address. For an empty IP lookup, the application reads the Cloudflare visitor headers available on the current request; the code path does not send that visitor IP to Radar. Header availability depends on the Cloudflare configuration in front of the request.

Cloudflare documents both the Radar IP-details endpoint and the optional visitor location headers. Geographic information should be treated as approximate network attribution, especially for VPNs, mobile networks, enterprise gateways, and cloud infrastructure.

Coverage matrix: source, freshness, and limits

Live data versus cached data

“Live” should never be read as “perfectly current.” A public-profile route may be checked at the time of a username query, yet the platform can be slow, rate-limited, changed, or return an inconclusive response. The separate scan API and Cloudflare Radar are external services whose response timing and freshness are provider-dependent. Google organic results are additionally cached by this application for up to seven days per query and country, so the user can receive a previous result during that cache window. Radar responses are cached for up to 15 minutes.

The application’s AI search-result and AI-summary switches are disabled in the current configuration. They are deliberately excluded from every count and diagram on this page. The same principle applies to inactive or unconfigured flows: domain, DNS, RDAP, and WHOIS are not listed as public coverage merely because they are common OSINT topics.

How the interface labels uncertainty

For usernames, the front-end recognizes Found, Not Found, and Error; any other upstream value is treated as Unknown. For email addresses, the corresponding recognized labels are Registered, Not Registered, and Error, with unexpected values treated as Unknown. IP lookups are context lookups rather than an account-existence test, so their fields should be evaluated with source labels and network context instead of a binary identity conclusion.

• Found / Registered means the selected source returned a positive candidate under its own rules. It does not prove that the account belongs to the searched person.
• Not Found / Not Registered means that route did not produce a positive match at that time. It does not prove that no account, alias, private profile, or differently formatted identifier exists.
• Error / Unknown means do not force a conclusion. It can reflect an unavailable route, an unexpected response, a temporary problem, or a source that cannot classify the check confidently.

This is why good investigations seek independent corroboration. A username can be reused, a search result can be stale, an IP may represent shared infrastructure, and a profile can be renamed. Our guide to false positives in OSINT results explains how to preserve and test competing explanations.

What is sent, what is retained, and where to check policy

Routing is part of transparency. Username queries can go to the configured public-profile worker, the separate scan API, and the Serper route when it is enabled and allowed. Email queries can go to the separate scan API and the eligible Serper route. A submitted IP can be sent server-side to Cloudflare Radar, while a blank visitor-IP lookup reads the current request’s available Cloudflare headers instead. Do not submit a sensitive identifier unless you understand and accept the relevant routing and have a lawful purpose.

The application creates and updates search-history records for username and email searches, including the submitted query, timestamps, selected result content, and a request-IP field. The project privacy page explains that searches and result summaries may be retained to provide continuity. It does not support an assumption here about a retention period that this coverage review did not establish. Please read the current Privacy Policy and Methodology before use, and use only data and identifiers within your authority.

More sources do not automatically mean better results

Coverage is a starting point, not a quality score. Adding sources can broaden discovery, but it can also increase duplicate profiles, stale evidence, inconsistent naming, rate-limit failures, and confident-looking false positives. A defensible workflow records the exact input, query time, source label, result URL or response context, and the alternative explanations considered. It separates discovery from verification.

Do not turn a matching handle, a location estimate, or a search snippet into a claim about a person without corroboration.

For username work, compare account-age signals, public cross-links, independent posts, and context rather than relying on a single match. For brand-protection research, verify the domain, official channels, and sender context before escalating; see How to Spot Brand Impersonation Online. For a fuller comparison of public username-checking approaches, read SpiderFoot vs Sherlock vs Maigret vs WhatsMyName.

What this service does not claim to cover

The current public configuration does not expose a domain, DNS, RDAP, or WHOIS search workflow. It does not claim complete web indexing, every social network, complete country coverage, continuous real-time monitoring, private-account access, private messages, passwords, credentials, mailbox access, or identity attribution. It also does not identify a named breach-data provider in the public source reviewed for this snapshot, so it makes no breach-coverage claim.

Those boundaries matter. A result can be useful for a defensive investigation, privacy review, incident triage, or authorized brand-protection task while still being incomplete. If the question requires a higher-confidence conclusion, collect lawfully available corroborating evidence and follow your organization’s policy, legal process, and data-minimization requirements.

How coverage changes

Coverage can change in four ordinary ways: a public platform changes its route or response behaviour; maintainers add, update, or remove a definition; a configured provider changes availability or response quality; or this application changes a feature flag, cache policy, route, or consent boundary. Counts alone cannot show whether a route is healthy. For that reason, this article’s figures are paired with their meaning, data path, cache behavior, and exclusions.

If you find a reproducible issue, report the affected route, the time observed, the input format used, the visible outcome, and a non-sensitive example where appropriate. Avoid posting personal data, credentials, or attempts to defeat access controls. The FAQ and Methodology are the best starting points for current product guidance.

A practical checklist for responsible use

1. Define the legitimate question and the authority you have to ask it.
2. Use the smallest necessary input; do not bulk-submit identifiers “just in case.”
3. Read the source label and freshness context before interpreting the result.
4. Keep Unknown and Error unresolved rather than converting them into negatives.
5. Verify meaningful findings with independent, lawful public evidence.
6. Record uncertainty, source dates, and alternative explanations with any conclusion.

Watch: a field perspective on online investigation tools

For a practical overview of why source awareness and reproducible methods matter, this Bellingcat presentation introduces its Online Open Source Investigations Toolkit. It is included as external learning material, not as a claim that SpiderFoot.tools uses Bellingcat’s data or tools.

Frequently asked questions

Does 708 username definitions mean 708 databases?

No. It is the count of active public-profile check definitions in the local dataset on the snapshot date. Definitions are routes and response rules, not a count of user databases or guaranteed working platforms.

Are results real time?

Some checks evaluate live route or provider behaviour, but no result should be assumed perfectly current. Serper-backed organic results can be served from an application cache for up to seven days, and Cloudflare Radar IP details can be cached for up to 15 minutes.

Does an account match prove identity?

No. A matching username is a lead. Usernames are reused, profiles change, and public context can be misleading. Corroborate independently and document uncertainty.

Does the email feature search breach data?

This source-level review does not identify a named breach-data provider in the public application code. Accordingly, this page does not claim breach-data coverage.

Does IP location identify a person?

No. IP information is network context and location can be approximate. Shared networks, VPNs, mobile carriers, proxies, and cloud services make person-level attribution especially unreliable without additional lawful evidence.

Why can the same query look different later?

Public routes, search indexes, provider responses, browser-language filtering, cache state, and regional settings can change what is attempted or returned. Record the time and source context if the distinction matters.

Sources and further reading

1. Cloudflare Developers — Radar IP details API
2. Cloudflare Developers — Managed transforms and visitor location headers
3. Serper — API documentation
4. WhatsMyName — project documentation
5. WhatsMyName — data schema
6. Sherlock — adding and validating sites
7. Maigret — contribution and site-checking guidance
8. MDN — HTTP response status codes
9. MDN — HTTP redirects
10. Bellingcat — editorial standards and practices
11. Bellingcat — Presenting: The Bellingcat Online Open Source Investigations Toolkit