METHOD / CLASSIFICATION / LIMITS

How SpiderFoot.tools Produces a Result

A code-audited account of how the username, email, and IP workflows validate an input, request external sources, classify responses, and present uncertainty.

A returned card is a source-rule result, not proof of identity or ownership. A missing card is not proof that an account, mailbox, or person does not exist. The production scanner and the separate 2,000-check research benchmark also use different classifiers; this page labels that distinction explicitly.

01 / QUERY_TO_RESULT

The result path is specific to the input type

There is no single all-purpose OSINT engine. Username, email, and IP inputs use different validators, sources, caches, and output rules.

01
Input
Username, email, or IP
02
Normalize
Trim and validate
03
Dispatch
Select workflow sources
04
Response
Receive source output
05
Classify
Apply workflow rules
06
Review
Verify original context

Username

The browser trims the handle and permits letters, numbers, dots, underscores, and hyphens. It then runs the local definition/Worker path and 13 category requests. Eligible public-web results are separate.

Email

The address is trimmed and checked in the browser, then validated again when the history task is created. Eighteen category requests run in sequence. Eligible public-web results remain a separate output.

IP

A blank input reads available visitor-request fields. A supplied IPv4 or IPv6 address is validated and sent server-side to Cloudflare Radar. The IP workflow does not create the username/email history task.

02 / RESULT_STATUS_REFERENCE

Use the vocabulary the production code actually exposes

The public interface has two account-status vocabularies. The username Worker also has internal reason text that is not fully rendered in the current scan log.

Production result statuses and their interpretation
Workflow / state	What triggers it	What it supports	What it does not support
Username: Found	The scan API returns `Found`, or a Worker definition returns `success=true` and `exists=true`.	A candidate public route under the current rule.	Identity, ownership, authenticity, or account linkage.
Username: Not Found	The scan API returns `Not Found`. A Worker definition can separately match its missing rule.	That source or rule produced a negative observation at that time.	Permanent absence, every spelling, or every public/private route.
Username: Unknown	The API status is empty or unrecognised, or neither Worker existence nor missing conditions match.	The response could not be classified by the available rule.	A positive or negative conclusion.
Username: Error	The scan API reports `Error`; whole category or Worker request failures are also tracked as partial errors.	The check was unsuccessful or incomplete.	Anything about account existence.
Email: Registered	A category item returns the exact positive status `Registered`.	A registration-style account-context lead.	Mailbox existence, delivery, current control, or identity.
Email: Not Registered	A category item returns `Not Registered`.	A negative result from that category response.	That the address has no accounts or public references.
Email: Error / Unknown	The item reports an error, or the status is empty or unrecognised.	The result is unresolved.	A negative mailbox or account finding.

Important implementation boundary: Blocked, Rate Limited, and Timeout are not separate production UI statuses in the code reviewed. They are explicit states in the independent benchmark dataset described below. Production category request failures are recorded as partial errors; ambiguous Worker results are non-positive and do not receive candidate cards.

03 / USERNAME_METHOD

A definition is a rule, not an account record

OPEN USERNAME SCANNER

The bundled JSON contains 708 active public-check definitions in 21 categories. Four are tagged for Chinese-language browser contexts; the other 704 are unrestricted. Browser-language filtering can therefore reduce the set attempted in one session.

708active definitions

21catalog categories

13scan-API categories

174preferred display URLs

The 13 scan-API category labels are: Social, Gaming, Music, Creator, Community, Shopping, Developer, Donation, Email, Finance, Other, Political, and Adult. These API categories are a separate source path from the 21-category local definition catalog; their counts should not be added together as if they were unique websites.

What a definition supplies

The Worker uses the site name, category, a check-route template, configured existence conditions, and configured missing conditions. A definition may also contain a preferred public profile URL, request headers, a POST body, or a language tag.

The encoded username replaces the {account} placeholder. The Worker follows normal redirects, reads the returned HTML text, and evaluates the response after the redirect. It does not render client-side JavaScript or score the redirect chain.

Positive conditions: 706 definitions require the configured status and text marker; two use the configured status alone.
Missing conditions: 670 use configured status plus missing text; 38 use configured status alone.
Batching: Current configuration sends six definitions per Worker request with at most five Worker requests in flight.
De-duplication: Positive Worker and API items merge by normalized hostname when possible, otherwise by normalized site name.

What the displayed 100 means: it is assigned when the current rule classifies an item as positive. No calibrated probability model, benchmark-derived accuracy score, or identity-confidence model was found in this path. HTTP 200 alone is not identity proof, and in most local definitions it is not enough to satisfy the positive rule.

04 / THIRD_PARTY_FAILURES

Unknown is a valid result

Public sites and providers control their own availability and response behavior. A transport or classification failure must not be promoted into an account claim.

Third-party changes and current scanner effects
External condition	Current code-path effect	Research conclusion
Changed HTML or missing marker	A Worker rule may become Unknown or incorrectly satisfy a stale condition.	Open the source and verify the page state.
Redirect to login, home, or challenge	Redirects are followed but the chain and final destination are not separately scored.	Do not treat the transport success as a profile.
JavaScript-only profile content	The Worker reads the initial response text; it does not execute the page application.	A real profile may remain undetected.
Category request or network failure	Username and email workflows count a partial error and continue other categories when possible.	Coverage is incomplete; no account conclusion follows.
Rate limit, CAPTCHA, or access block	No dedicated production status branch is defined locally. It may appear as an upstream Error/Unknown, an internal Worker non-positive, or a failed request.	Leave the check unresolved. Do not bypass the control.
Cloudflare Radar unavailable	The server returns an IP lookup error rather than empty successful fields.	Retry later; it says nothing about the IP owner.

Timeout and retry boundary: the reviewed production Worker call includes a timeout: 10000 request option, but it does not attach an explicit abort signal and has no per-site retry loop. This page therefore does not claim that every Worker check is forcibly cancelled after ten seconds. Username and email category failures continue to later categories without an automatic retry; the separate Radar IP request has an enforced ten-second cURL timeout.

Practical reading rule: the code does not intentionally convert a failed category request into Not Found. However, the candidate grids are positive-only, so an empty grid can coexist with ambiguous or failed checks. Read the scan log and partial-error warning; do not rewrite “no positive card” as “account does not exist.”

05 / EMAIL_METHOD

Account-context checks, not mailbox verification

OPEN EMAIL SCANNER

The scanner sends the full trimmed email address with one request for each of 18 categories. The project does not publicly name the upstream providers behind that separate category API, so this page does not invent provider coverage.

Configured categories

SocialMusicGamingJobsNewsShoppingSportsLearningDeveloperAdultCommunityCreatorCRMEntertainmentFitnessHostingOtherTravel

DETERMINISTIC_APP_RULE

What becomes a card

Only an item whose returned status normalizes to Registered becomes a positive card. Cards are de-duplicated by normalized site name, URL, and email.

RESEARCH_SIGNAL

Public-web context

Where enabled and permitted by country rules, Serper-backed Google organic results appear separately. The application can cache them for seven days.

NOT_CHECKED_HERE

Mail transport and private data

No MX, DNS, SMTP delivery, mailbox access, named breach provider, reputation, disposable-address, avatar, RDAP, or WHOIS check was found in this path.

A Registered signal is not proof that the address is deliverable, that its owner controls an account now, or that the same person controls every returned account. Aliases, forwarding, role addresses, recycled accounts, provider concealment, and source changes all limit interpretation. No displayed card means only that this run returned no positive card.

06 / IP_INTELLIGENCE_METHOD

Separate the visitor connection from a researched IP

OPEN IP LOOKUP

VISITOR_IP

Current request headers

With no input, the origin reads the current request IP and any available Cloudflare visitor-location headers: country, city, continent, coordinates, region, metro code, postal code, and timezone. Missing fields stay visible as unavailable. This path does not send the visitor IP to Radar.

RESEARCHED_IP

Cloudflare Radar details

A complete IPv4 or IPv6 address is validated in the browser and again on the server. The server queries Cloudflare Radar and can return IP version, ASN, autonomous-system name, organisation, ASN location, and location labels. Successful data can be cached for 900 seconds. The server request has a 10-second cURL timeout.

Interpretation limits: an IP is not a person; geolocation is not an exact address; an ISP or ASN owner is not necessarily the end user or website owner. VPNs, proxies, CDNs, hosting providers, mobile networks, carrier-grade NAT, enterprise gateways, dynamic assignment, and routing changes can all shift the correct conclusion.

07 / FALSE_POSITIVES_AND_NEGATIVES

Detection error and identity error are different

A technical false positive means the source rule accepted the wrong kind of page. An identity false positive means the page is real but was attributed to the wrong person or organisation. A false negative means a real public account was missed or left unresolved.

Common false-positive paths

a soft 404 or generic profile shell satisfies a stale rule;
a login, search, home, or challenge redirect looks successful;
a platform redesign or localization changes the meaning of a text marker;
a shared, reassigned, copied, or impersonated handle is attributed to the wrong owner;
a cached search snippet or dependent aggregator is treated as current independent evidence.

Common false-negative paths

the profile is private, renamed, moved, or behind authentication;
anti-automation, rate limiting, regional behavior, or an outage prevents the check;
the profile content appears only after client-side JavaScript executes;
the platform treats case, punctuation, aliases, or normalization differently;
the local definition or upstream provider behavior is outdated.

The companion field guide separates 50 patterns into observed benchmark signals, controlled non-personal fixtures, and documented recurring mechanisms.

READ 50 CASES

08 / REPRODUCIBLE_BENCHMARK

100 non-personal usernames × 20 fixed platforms

The 4 September 2026 research run contains 2,000 pre-registered username/platform combinations. It used a purpose-built public HTTP probe, not the production Worker or scan API, so its states and counts are not a product accuracy score.

100non-personal handles

20frozen platforms

2,000unique checks

1,115indeterminate outcomes

Execution policy

four equal 25-handle cohorts: synthetic unique, generic pattern, public organisation, and public project;
one unauthenticated connection at a time, at least 0.25 seconds between requests;
seven-second request timeout; no proxy, cookie reuse, login, CAPTCHA bypass, or automatic retry;
FOUND required a 2xx response and a page title containing the queried handle;
404 became NOT_FOUND; 401/403 became BLOCKED; 429 became RATE_LIMITED; ambiguous 2xx became UNKNOWN; server/request failures became ERROR.

The probe read at most the first 65,536 response bytes for the title check. One interrupted host session produced 35 duplicate raw events; the canonical CSV keeps the first chronological event for each pre-registered pair.

Canonical outcomes

FOUND: 387
NOT_FOUND: 498
UNKNOWN: 437
BLOCKED: 574
RATE_LIMITED: 100
ERROR: 4

All 387 first-pass candidates received a second public route review: 384 met the narrow route-confirmation rule and three remained indeterminate. This did not verify identity or ownership.

Inspect the published data

2,000-row reviewed results CSV Per-platform summary CSV 100-handle input CSV Frozen platform CSV

The repository also retains the probe, canonicalization, evidence-review, and analysis scripts. Reproducibility still has limits: this was one network, one time window, a deliberately non-personal sample, and a conservative title-based rule without complete account ground truth.

READ THE FULL BENCHMARK METHOD

09 / EVIDENCE_AI_AND_HISTORY

Interpretation layers do not replace source evidence

Evidence hierarchy

01.External source or provider response
02.Definition or status-adapter rule
03.Scanner status and source link
04.Separate public-web or AI-assisted context
05.Human, purpose-specific interpretation

Current feature state

The codebase contains AI Search and AI Summary implementations, but both panels are disabled in the public feature flags at this snapshot. Serper-backed organic results are enabled separately where country rules permit them; they are search context, not AI verification.

If AI panels are enabled later, their output is stored and rendered separately from common scan results. The reviewed code does not use an AI response to change a Worker existence decision, an API Found/Registered status, or an IP provider field.

Username and email searches create application history tasks and can save the submitted query, timestamps, selected positive results, public-web output, and separate AI fields. The IP lookup is not part of that history workflow. Read the Privacy Policy before submitting an identifier.

10 / RE_TESTING_AND_CORRECTIONS

Definitions can fail when sources change

A profile route, response marker, redirect, login requirement, API payload, rate limit, or page-rendering model can change without this application changing. That can create stale rules, missing cards, false positives, or new Unknown responses.

What is present in the repository

snapshot generators for username matching, email checks, source coverage, and false-positive research;
a benchmark probe, canonicalization script, second-pass evidence collection, and analysis code;
timestamped CSV/JSON evidence and public benchmark downloads.

What was not confirmed

an automated regression suite covering all 708 production definitions;
scheduled source-health monitoring or automatic rule repair;
manual review of every user scan or a fixed re-test cadence;
a measured production-wide accuracy, precision, or recall percentage.

Report a reproducible problem

Use Contact for a false positive, false negative, broken source, outdated definition, or incorrect Methodology statement. Include the affected platform or page, query type, observed result, expected result, approximate time, relevant public URL, and safe reproduction information. Do not send credentials or unnecessary personal data.

Corrections to published research follow the separate Editorial Policy correction process. No fixed response or repair deadline is promised.

RELATED_RESEARCH

Inspect the supporting work

How SpiderFoot.tools Finds Username MatchesDefinition fields, Worker decisions, merging, and absent-card limits. Email OSINT: What Our Scanner Actually ChecksThe 18 categories, data paths, status handling, and explicit exclusions. Our OSINT Data Sources & CoverageNamed sources, cache windows, routing, and coverage boundaries. How Accurate Are Username OSINT Tools?Detection accuracy, attribution, Unknown states, and benchmark design. We Tested 100 Usernames Across 20 PlatformsThe complete 2,000-check method, review rubric, data, and limits. 50 Common OSINT False Positives We FoundA source-labelled field guide for testing alternative explanations.