MyRecon OSINTWhy Username Checkers Report Accounts That Don't Exist
Run a handle through almost any username-search tool and you will get a wall of green ticks. Click a few and you will find pages that say the account is not there. This is not a bug in one tool — it is a structural problem with how these checks work, and we can show you the measurements that prove it.
The test that exposes it
There is one experiment that separates a username checker that works from one that is guessing, and you can run it in under a minute. Search for a handle that cannot possibly exist — a string of nonsense nobody would ever register. We use zzqnope99123xqq. Then compare the results against a handle you know is real.
If the tool reports accounts for the nonsense string, every result it gives you is suspect, because it is not detecting accounts. It is detecting that a web page loaded.
We ran exactly this across a range of platforms, comparing the HTTP status code and the response size for a real handle against an invented one. The results below are raw measurements, and you can reproduce all of them with a browser and its developer tools.
Some platforms return the identical page either way
This is the core of the problem. Here is what several well-known platforms returned for a real handle versus an invented one, measured the same minute:
Platform real handle invented handle
Discord 200 (63,660 bytes) 200 (63,660 bytes)
WhatsApp 200 (220,565) 200 (220,536)
MeWe 200 (15,465) 200 (15,465)
Battle.net 200 (4,776) 200 (4,776)
Matrix 200 (2,774) 200 (2,774)
EyeEm 200 (2,186) 200 (2,186)Look at Discord and MeWe: not merely a similar response, but the same number of bytes. The server produced identical output for a real account and a string we invented seconds earlier. There is no signal in that response. None. Any tool reporting a Discord account from a check like this is reporting the fact that discord.com is online.
WhatsApp differs by 29 bytes out of 220,565 — that is the handle itself echoed back into the page, not evidence of anything.
Why so many sites behave this way
It is rarely deliberate obstruction. Three ordinary engineering decisions produce it:
Single-page applications
Modern web apps ship an empty HTML shell and build the page in the browser with JavaScript. The server sends the same shell for every URL under the domain, and only after the JavaScript runs and calls an internal API does the page discover whether the profile exists. A tool that reads the raw HTML — which is what all of them do — sees the shell and nothing else.
Login walls
Many platforms now require an account to view profiles. Requesting a profile URL while logged out returns the login page, which is naturally identical whether or not the profile behind it exists. A crude checker sees HTTP 200 and calls it a match.
Soft 404s
The correct response for a missing page is HTTP 404. Plenty of sites instead return 200 with a "user not found" message in the body, because it is simpler or because a marketing team wanted a branded page. Status code alone cannot distinguish this from a real profile.
The tautology trap
Once you accept that status codes are unreliable, the obvious next step is scoring: award points for signals suggesting a real profile, and require a threshold. This is what better tools do, and it is where a subtle failure creeps in.
Consider a scorer that awards a point when the handle appears in the final URL. It sounds reasonable. It is worthless, because we requested that URL. The handle is in the response URL for the same reason it is in the request: we put it there. The point is free, and it is awarded to real and fake handles alike.
The same applies to two other tempting signals. A page having a meta description does not indicate a profile — nearly every page on the web has one. A page having an og:image does not either, because most sites set a default share image sitewide.
Add those three "signals" together and a platform that answers 200 for everything scores three points before any real evidence is examined. Here is a scoring breakdown we captured, showing where the points came from:
URL title canon url type img desc TOTAL
duolingo.com/profile/<real handle> 0 2 1 0 1 0 4
duolingo.com/profile/<invented handle> 0 2 1 0 1 0 4Identical. The real handle and the invented one scored four points each, and four was enough to be reported as a high-confidence match. Not one of those points came from evidence that an account existed.
What a real signal looks like
The fix is to separate signals that could only come from a page rendered for that specific account from signals that any page on the domain would produce.
Only two things reliably meet that bar across platforms:
- The handle in the page title. A profile page is titled for its owner. A generic shell is titled for the site — "Twitch", "Trello", "WordPress.com". This single check does most of the work.
- Rendered social statistics. Follower and following counts are per-account by definition. A site cannot show them without having looked the account up.
Everything else — canonical URLs, OpenGraph type, share images, descriptions — is corroboration. It can raise confidence once real evidence exists, but it must never create a match on its own.
Applying that gate to a real scan changed the reported results substantially. Of 16 accounts previously reported for one handle, 11 disappeared. Those 11 were Duolingo, Twitch, Trello, WordPress, Spotify, Trakt, HackerRank, Odysee, Giphy, CoinMarketCap and Instructables — every one of which had been listed as a confirmed account, and every one of which scored identically for a handle that could not exist.
The cost of getting this right
Honesty here has a price, and any tool claiming otherwise is hiding something. A real profile on a site that renders entirely client-side produces no evidence either way. The strict answer is to report it as unconfirmed rather than found.
That means you will miss some real accounts. It is the correct trade for anything whose value depends on its results being true — a list of twenty accounts where nine are imaginary is worse than a list of five that are all real, because you cannot tell which nine.
The better resolution is not to hide the uncertain results but to label them. "Found", "possible" and "could not verify" are three different statements, and collapsing them into one green tick is the original sin of this entire category of tool.
Not found and could not check are different
One more distinction matters, and almost every tool gets it wrong. When a platform rate-limits you, blocks your address, or times out, that is not evidence the account is absent. It is the absence of evidence.
We saw this vividly with Instagram. From one network, its API returned HTTP 429 for every handle we tried — including Instagram's own official account. A tool that treats a failed check as "not found" would confidently report that Instagram does not have an Instagram account.
Platforms also behave differently depending on who is asking. The same check that a cloud server is refused for is often answered for a phone on a mobile connection, because datacentre address ranges are blocked far more aggressively than residential ones. Two tools can therefore disagree completely and both be reporting honestly.
How to evaluate any username tool
Three questions, in order of how much they tell you:
- What does it return for an invented handle? Anything other than nothing means its results cannot be trusted at face value.
- Does it distinguish "not found" from "could not check"? If every non-result looks the same, you cannot tell a clean sweep from a blocked one.
- Does it show you what it rejected, and why? A tool willing to say "we checked 112 platforms, here is what each answered" is one that has thought about being wrong.
Try it yourself
MyRecon reports its results by confidence and tells you which platforms it checked but could not confirm, including the reason each one gave. Run your own handle, then run a string of nonsense, and compare — that comparison is the honest measure of any tool in this category, including ours.