We Tested 100 Usernames Across 20 Platforms

Short answer: a username lookup is a useful way to generate public leads, but it is a poor substitute for verification. To see how much uncertainty a simple public-profile check carries, we tested 100 non-personal usernames across 20 fixed public platforms: 2,000 pre-registered username/platform combinations in total. The result was not a tidy “found or not found” story. Only 387 checks (19.4%) produced a technical candidate; 498 (24.9%) were explicit 404s; and 1,115 (55.8%) were deliberately retained as indeterminate rather than silently treated as negative.

This is an original, reproducible measurement for SpiderFoot.tools. It is not a claim that one product “wins,” a population estimate of how common usernames are, or a method for identifying a person. It is a controlled snapshot of how 20 public profile routes behaved from one network at one point in time.

What we tested—and what we did not

Each check sent one ordinary, unauthenticated HTTP request to a platform’s documented or widely used public profile-route pattern, such as https://github.com/{username}. The detector marked a route as a technical FOUND candidate only when it received a 2xx response whose HTML title contained the queried handle. A 404 was kept as NOT_FOUND. A 2xx response without that title evidence was UNKNOWN, and access controls, rate limits, and server failures remained separate states.

The frozen platform set was GitHub, GitLab, Codeberg, Hugging Face, Docker Hub, npm, PyPI, SourceForge, DEV Community, Hashnode, CodePen, JSFiddle, Hacker News, Reddit, Mastodon.social, Medium, Tumblr, Vimeo, Behance, and Keybase. Every cohort was checked against every platform: 100 × 20 = 2,000 unique combinations.

The request policy was intentionally conservative: one connection at a time, a 0.25-second global minimum interval, seven-second timeout, no authentication, no proxy, no CAPTCHA or anti-bot bypass, no cookie reuse, and no automatic retries. The probe identified itself as SpiderFootToolsUsernameBenchmark/1.0. It saved only the route, final URL, status, redirect observation, title-match boolean, timing, and review label—never profile text, emails, posts, or private data.

Reproducibility and a small raw-log caveat

The research package retains the 100-handle input CSV, frozen platform configuration, probe, analysis code, raw event log, candidate-review evidence, and chart-generation code. For readers who want to inspect the published, canonical data without collecting anything themselves:

• Download the 2,000-row reviewed results CSV
• Download the per-platform summary CSV
• Download the 100-handle input list and the frozen platform list

One operational detail matters for honest reporting. The probe itself made no automatic retries, but a host-session interruption during the run caused 35 already-observed combinations to be written again when the job resumed. We preserved all 2,035 raw HTTP events. For the pre-registered analysis, the canonical dataset takes the first chronological observation for each username/platform key—exactly 2,000 unique combinations—and does not select the more favorable duplicate.

Headline results: uncertainty was the majority outcome

Across the canonical 2,000 checks, we observed 387 technical FOUND candidates, 498 explicit NOT_FOUND responses, 437 UNKNOWN responses, 574 BLOCKED responses, 100 RATE_LIMITED responses, and four ERROR responses. Grouping the last four categories as indeterminate is useful for visualization, but they remain separate in the downloadable data.

The result is not a league table. Hugging Face produced the most technical candidates in this snapshot (67), while GitHub and Docker Hub each produced 59; that says more about this frozen input set and these public routes than it does about platform completeness. Conversely, PyPI, SourceForge, Hacker News, Medium, Behance, and much of npm/CodePen/Tumblr were dominated by unknown, access-denied, or rate-limited outcomes. Calling those outcomes “no account” would have fabricated 1,115 negatives.

The cohort result that matters most

The 25 synthetic unique handles produced zero technical candidates across 500 checks. They produced 226 explicit 404s and 274 indeterminate outcomes. That is reassuring as a narrow control signal: this title-based probe did not falsely report any of our purpose-made strings as candidates on the accessible routes. It does not establish a general false-positive rate, because there is no independent ground-truth registry for all 2,000 account possibilities.

How we reviewed candidate and negative results

Every one of the 387 first-pass FOUND candidates received a second, separately logged public review request. The rubric was intentionally narrow: a candidate became VERIFIED_PUBLIC_ROUTE only when the second response was 2xx and the returned title again named the queried handle. 384 of 387 met that route-confirmation rule. Three remained INDETERMINATE_AT_REVIEW because their follow-up pages did not expose sufficient title evidence. No candidate was reclassified as a technical false positive under this particular rule.

That sentence deserves a boundary: “verified public route” means the page route behaved like a visible account/organization/project page at review time. It does not mean the profile is official, active, controlled by a particular party, or connected to another same-named profile. It is deliberately weaker than identity verification.

We also took a deterministic stratified sample of available NOT_FOUND results—one synthetic and one non-synthetic handle per platform where such rows existed. Only 23 routes qualified because several platforms produced no 404s at all. Twenty follow-up requests remained 404. Three responses changed to 403 challenge pages. We left all three as the original observed 404 in the canonical measurement and did not turn the later access control into a positive or negative claim. This is exactly why timestamped raw status is more useful than a single “exists” flag.

What this says about SpiderFoot-style username research

SpiderFoot’s account-discovery module draws on public account-site definitions, while projects such as WhatsMyName, Sherlock, and Maigret maintain evolving site logic and response rules. Their scope, detector logic, and current site data are different. This article therefore does not compare their recall, precision, speed, or “winner.” It tests one transparent HTTP baseline so the failure modes are visible.

The practical lesson for a SpiderFoot.tools workflow is straightforward: use a username result to create a review queue, then open the public source, check whether the route really identifies the intended account, record the timestamp, and look for independent context. A shared string alone is not corroboration. That is consistent with our related guide, What Can Someone Find From Your Username?, and our analysis of why OSINT results can be wrong.

A safer operating procedure for real investigations

1. Define authority and the question. Are you self-auditing a brand, responding to an authorized incident, or researching a public organization? Do not turn curiosity into person-tracking.
2. Record the source state. Keep the exact URL, collection time, HTTP behavior, redirects, and why a result is only a candidate. A 429 or access block belongs in the record.
3. Validate at the source. Read the public profile page. Look for independent, non-sensitive context—official links, verified domains, published project references, or consistent organizational signals—not just the same handle.
4. Write a bounded conclusion. Say “a public route was observed” rather than “this account belongs to X” unless you have separate, defensible evidence and authority to make that claim.

Limits readers should keep in view

• This is one network environment and one UTC test date; platforms change templates, protection policies, and routing frequently.
• The 100 inputs are intentionally non-personal and balanced by cohort. They are not a sample of all people, brands, or usernames.
• The title-match detector is conservative but imperfect. A profile can exist without a matching title, and a matching title never proves ownership.
• We did not authenticate, solve challenges, rotate IPs, or retry. That protects scope and makes blocked/unknown outcomes expected rather than errors to “fix.”
• There is no complete external ground-truth set for the 2,000 possibilities, so this article does not report accuracy, precision, recall, or false-negative rate.
• The 35 duplicated raw events are retained for audit; all public counts use the documented first-observation canonical rule.

Conclusion

We tested 100 usernames across 20 platforms and learned something more useful than a simplistic score: in a real public-web workflow, indeterminacy is common. The disciplined response is not to force ambiguous pages, blocks, and rate limits into a binary answer. It is to preserve them, verify visible routes, document what was actually observed, and resist identity claims that the evidence cannot support.