A code-audited account of how the username, email, and IP workflows validate an input, request external sources, classify responses, and present uncertainty.
01 / QUERY_TO_RESULT
There is no single all-purpose OSINT engine. Username, email, and IP inputs use different validators, sources, caches, and output rules.
Username, email, or IP
Trim and validate
Select workflow sources
Receive source output
Apply workflow rules
Verify original context
The browser trims the handle and permits letters, numbers, dots, underscores, and hyphens. It requests the configured scan-API categories, following each category’s pages in order. Several categories can run concurrently. When Privacy Search is enabled, it skips the history task and task-dependent AI enrichment; public-web results can still load without being stored in history.
The address is trimmed and checked in the browser. Configured category requests run in sequence. When Privacy Search is off, the history endpoint validates it again while creating the task; when enabled, task creation and task-dependent AI enrichment are skipped while public-web results remain available without history storage.
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
Username and email checks use different account-status vocabularies. Each returned site record appears in the scan log with its status and any supplied reason; only positive statuses produce candidate cards.
| Workflow / state | What triggers it | What it supports | What it does not support |
|---|---|---|---|
| Username: Found | The scan API returns Found for a site. | A candidate public route reported by the provider. | Identity, ownership, authenticity, or account linkage. |
| Username: Not Found | The scan API returns Not Found for a site. | That source 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. Additional upstream status text can remain visible in the log. | The response remains unresolved in the interface. | A positive or negative conclusion. |
| Username: Error | The scan API reports Error for a site. A failed category page is tracked separately as a partial error. | 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. |
Blocked, Rate Limited, and Timeout have no dedicated classification branches in the production frontend. Additional upstream status text is treated as non-positive. The independent benchmark below defines its own states. Failed category pages are recorded as partial errors.
03 / USERNAME_METHOD
The username scanner uses the scan API, with configured coverage of up to 2,539 sites across 17 categories. Each category can return several pages. The interface displays the site records supplied by those pages and uses their returned statuses to identify candidate profiles.
Configured categories: Social, Creator, Developer, Creative, Community, Gaming, Entertainment, Music, Learning, Shopping, Donation, Finance, Email, Other, Dating, Political, Adult. The site count is a coverage reference; the number of returned records can vary with source availability and the pages supplied by the API. Download the published site lists to inspect individual sites and modules.
Several categories can run concurrently, while pages within each category are requested in order. The next page is requested only when the API says another page is available.
04 / THIRD_PARTY_FAILURES
Public sites and providers control their own availability and response behavior. A transport or classification failure must not be promoted into an account claim.
| External condition | Current code-path effect | Research conclusion |
|---|---|---|
| Changed HTML or missing marker | A provider check can become stale; the browser displays the status returned by the scan API. | Open the source and verify the page state. |
| Redirect to login, home, or challenge | The interface displays the URL returned by the API without independently checking its redirect chain or final page. | Do not treat the transport success as a profile. |
| JavaScript-only profile content | The browser does not open or render each target site during the category scan. Detection depends on the API’s site checks. | 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 | The API may return Error or another unresolved status, or the page request may fail. The frontend has no dedicated block or rate-limit classification. | 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. |
When error reporting is enabled, each category page can send one diagnostic report for its network or HTTP failures, including failures recovered by switching APIs. Each scan allows up to 50 report attempts across all categories and pages; failed and pending reports count toward this limit. Reaching the limit stops further reporting while the scan continues. A new scan starts with a fresh allowance. A report marks total failure only when every candidate API has failed. Reporting runs separately from the scan, does not delay its results, and does not retry its own failures. See the privacy notice for the diagnostic data involved.
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.”
SpiderFoot.tools is a hosted preview whose requests may inherit the reputation and restrictions of shared public-server IPs. Target-side 403 or 429 responses, anti-bot challenges, regional controls, redirects, and timeouts can reduce observed coverage without proving absence.
For a broader authorized username or email scan, kaifcodec/user-scanner can be installed and run from the command line in your own network environment. That may avoid some hosted-infrastructure restrictions, but it is a change of vantage point rather than an accuracy guarantee. See the usage guide for the dated project-maintenance comparison and recommendation boundary.
05 / EMAIL_METHOD
The scanner sends the full trimmed email address to each of 20 configured categories in sequence, following additional pages while the API reports more results. Those categories currently contain 220 API sites in total. The published site lists provide module names, categories, and source URL templates for reference.
220 sites / 20 categories
DETERMINISTIC_APP_RULE
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
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
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 / SITE_LIST_DOWNLOADS
Browse the individual sites and modules in the published scan inventories. Both Excel attachments were prepared on .
2,539 active modules across 17 categories.
Includes a separate worksheet with 10 retired modules for historical reference.
DOWNLOAD USERNAME LISTExcel workbook (.xlsx), 122.6 KiB
220 active modules across 20 categories.
Includes a separate worksheet with 9 retired modules for historical reference.
DOWNLOAD EMAIL LISTExcel workbook (.xlsx), 17.5 KiB
Each workbook contains Active Modules and Retired Modules worksheets with site names, categories, module IDs, source URL templates, and relative source file paths. Retired modules are excluded from active scans. Live availability was not tested for these exports, and current API totals can differ as modules or deployments change.
07 / IP_INTELLIGENCE_METHOD
VISITOR_IP
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
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.
08 / FALSE_POSITIVES_AND_NEGATIVES
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.
The companion field guide separates 50 patterns into observed benchmark signals, controlled non-personal fixtures, and documented recurring mechanisms.
READ 50 CASES09 / REPRODUCIBLE_BENCHMARK
The 4 September 2026 research run contains 2,000 pre-registered username/platform combinations. It used a purpose-built public HTTP probe, separate from the production scan API, so its states and counts are not a product accuracy score.
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.
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.
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 METHOD10 / EVIDENCE_AI_AND_HISTORY
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 an API Found/Registered status or an IP provider field.
With Privacy Search off, 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. With Privacy Search on, task creation and history saving are skipped. Public-web results can still load without a task ID and are not written to history; task-dependent AI enrichment is skipped. Required providers still receive the query. The IP lookup is not part of the username/email history workflow. Read the Privacy Policy before submitting an identifier.
After you submit a query, Google Dorks offers search links based on that exact username or full email address. Each shortcut explains its scope through a question-mark help button. Opening a link sends the generated search to Google in a new tab, including when Privacy Search is enabled. These are independent searches of Google's index; they do not affect the scan progress or establish account ownership. You can inspect and copy every generated query before opening it.
IP lookups offer six separate shortcuts for exact mentions, security mentions, technical discussions, public documents, recent mentions, and hosting or network context. They appear only for a valid public IP. A manually entered public IP can be searched even if its metadata lookup fails; with a blank input, the current connection's public IP must first be available. Private, loopback and reserved addresses do not receive shortcuts. These links are generated locally and send the selected IP to Google only when opened. Check each record's date and context: an IP can be shared or reassigned, and a search match does not identify its current user or prove malicious activity.
11 / RE_TESTING_AND_CORRECTIONS
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.
Use Contact for a false positive, false negative, broken source, outdated site check, 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