A username search tool takes one handle and asks hundreds of platforms the same question: does an account with this name exist here, and what does its public page show? The answer is a ranked list of live profiles, not a list of guessed URLs. The difference between those two things is where most of the engineering goes, and it is what separates a tool you can rely on from a script that returns 40 hits, 25 of which are login walls.
I have run most of the open-source scanners in anger, and I built OSINTsearch because the workflow around them kept breaking in the same places. This post covers what a username search tool should return, how detection works, why false positives happen, and how to read a result set before you act on it.
What a username search tool actually checks
Every platform has a profile URL shape and an existence signal. GitHub answers 404 for a missing user. Instagram's logged-out HTML returns a 200 login wall for live, banned, and never-existed handles alike, so a tool that trusts the status code there is guessing. The upstream engine behind OSINTsearch uses Instagram's GraphQL endpoint instead, where a null user object is a genuine not-found and a banned account still returns its numeric id.
The output per platform is a normalized profile: platform, username, user id, display name, bio, location, avatar, follower and following counts, post count, verified flag, creation date, last-active date where the service exposes it, linked social accounts, and former usernames where a platform records renames. A tool that returns only a URL has not checked the account, it has constructed a link.
Coverage is the number people quote first, and it matters less than accuracy. OSINTsearch queries over 750 username platforms per scan, spanning social, gaming, creator, developer, forum and marketplace services, and the count moves as modules are added or retired when a site puts up a wall that cannot be read publicly.
Reverse username lookup: four outcomes per platform
A single scan produces one of four outcomes for each platform, and you should treat them differently. Found means the account exists and the profile is populated. Not found means the identifier is genuinely unregistered there. Rate limited means the platform throttled or blocked the request this run. Error means a parse or transport failure.
| Outcome | Meaning | Retry? |
|---|---|---|
| found | Account exists, profile returned | No |
| not_found | Identifier is not registered on that service | No |
| rate_limited | Throttle, WAF or bot check blocked the query this run | Yes, later or via proxy |
| error | Parse or transport failure | Yes |
Found plus not-found is the definitive set. In the engine's own measurements roughly 94 percent of modules return a definitive answer on a normal run, and that share holds under load; what load costs is time, not completeness. A full sweep takes about 30 seconds idle. The remaining few percent are the rate-limited and error modules, and a good tool tells you which ones they were rather than quietly folding them into "not found".
Where false positives come from
Most false positives in username scanners come from three sources. The first is a platform that returns 200 for every path, with the "no such user" message buried in the page body. The second is a brand or placeholder account: search for support or admin and dozens of services will return their own account. The third is a rename: the handle exists, but it belongs to someone who picked it up after the original owner moved on.
The first two are solvable in code. OSINTsearch validates hits against expected fields, drops brand accounts and placeholders before ranking, and pushes large, verified accounts to the top so the obvious matches are visible first. The third is not a code problem. It is an analyst problem, and the fix is corroboration: do the avatars, display names, bios and links agree across the hits? A handle held by four different people across four services is a common name, not a person.
Beyond the link list: former handles, last active, gone accounts
The results that change an investigation are rarely the profile URL. They are the fields around it. Instagram's about-this-account panel lists former usernames for many accounts, a last-active oracle tells you whether a profile is a living account or a shell, and a banned account still returns its numeric id. Here is a real result for a public account, pulled on 2026-09-05:
{
"platform": "instagram",
"username": "cia",
"user_id": "12630084296",
"display_name": "Central Intelligence Agency",
"verified": true,
"followers": 994909,
"location": "United States",
"created_at": "2019-04-01",
"last_active_days_ago": 0,
"former_usernames": ["mollyhalecia"]
}
Two fields in that record matter more than the follower count. The first is former_usernames: the agency's account was registered under the handle mollyhalecia and renamed later. The second is what a search on that old handle returns today. It resolves, but not to the CIA:
{
"platform": "instagram",
"username": "mollyhalecia",
"user_id": "13850880400",
"display_name": "Mollyhalecia",
"location": "Indonesia",
"created_at": "2019-05-01",
"last_active_days_ago": null,
"former_usernames": ["riajda243"]
}Different ids, different countries, one month apart in creation date, no last-active answer from the oracle, and the second account carries its own former handle, riajda243. The name mollyhalecia was released when the CIA renamed and someone else registered it. A tool that keys on the handle would tie the CIA's old name to an unrelated account in Indonesia. The numeric user id is the stable key: 12630084296 is the agency whatever it calls itself, and 13850880400 is whoever holds mollyhalecia this week. A deep search that reaches the second account takes riajda243 as its next hop, because that is the trail of the account it actually found, not a trail back to the first.
Banned and deleted accounts are the other class of result a link list cannot represent. The handle gambling on Instagram returns a 404 page, and a scan still returns user id 64124577206, the bio text "kiss", Instagram's default anonymous avatar, a status of banned_or_disabled, and a username field holding Instagram's localized "Instagram User" placeholder. The last-active oracle answers too: 858 days. A disabled handle is evidence, and the id lets you match it against archived posts and breach records after the name is gone. The post on finding a deleted Instagram account walks through two of these in full.
Bios and link pages get parsed for further handles, wallets and social links, which are checked in turn. The guide on finding old usernames covers the rename trail in more detail.
Free plan vs paid plans
You can run a live scan on osintsearch.org without an account and watch the platforms answer in real time. A free account gives 15 searches per week with every field shown: the username, display name, bio, location, exact counts, user id, joined date, former handles and last-active date, wherever a platform exposes them. The paid plans add volume, the CSV and JSON export, breach records and deep search, so the free row is enough to decide whether your workload is worth paying for.
Paid plans return the same rows in full. Starter is $20 per month for 50 searches a week, Pro is $49.99 per month for 500 a week plus deep search and full breach records, and Enterprise adds API access on custom terms. The pricing page has the current matrix. Every plan exports results as JSON and CSV, because a result you cannot carry into a report is a result you will end up retyping.
How this compares with running scripts
Sherlock, Maigret and WhatsMyName are good tools, and the honest position is that they are free and you should know how to run them. Their limits are the same ones I hit for years: site lists that rot as platforms change, detection rules that stop matching, no proxy rotation so the interesting platforms rate-limit you within minutes, and no former usernames, last-active dates or banned-account signals because those require endpoints that a static site list does not describe. The Sherlock alternative post goes through each one fairly.
A hosted tool trades a monthly fee for a maintained fleet: modules are health-checked against baselines, rate-limited modules are retried through proxies, and new platforms are added weekly. Whether that trade is worth it depends on how many scans you run and how much the extra fields matter to your work.
FAQ
Is a username search tool legal to use?
Querying public profile pages is lawful in most jurisdictions, but what you do with the results is governed by local law and platform terms. Do not use social search results for decisions covered by consumer reporting or employment law, and do not research people you have no legitimate reason to research.
How many platforms does OSINTsearch check per username search?
Over 750 username platforms per scan, read live. Email and phone lookups run against their own corpora on paid plans and are not part of a username sweep.
Why does the same handle show up on services the person never used?
Common handles are held by different people on different services. Corroborate with avatars, display names, bios, linked accounts and creation dates before treating hits as one identity.
Does the search notify the account owner?
No. Scans read public endpoints and never sign in, follow, message or trigger recovery emails.
Start with one clean handle
The best first scan is a handle you already know is the person: from a URL they shared, a signature, or a linked account. Run it, look at the ranked hits, and check whether the fields agree before you chase anything from the tail. A username search tool gives you the list in 30 seconds. Deciding which rows are the same human is still your job, and it is the part that matters.
