Fast browser access, with shared-server limits
Discover Profile is a preview interface for quick OSINT checks without installing or configuring the underlying scanner. Requests use shared public server infrastructure, so some target services may respond differently because of IP reputation controls, rate limits, bot protection, regional rules, CAPTCHAs, or temporary blocking.
How to interpret incomplete results
An HTTP 403, timeout, error, unknown status, or missing positive result may describe the network path or the target service's current policy—not the absence of an account. Treat every result as a lead and verify it at the original source.
For deeper or repeatable scans
Use the actively maintained open-source User Scanner project for its categorized username and email modules, targeted scans, and command-line workflow. Install it locally and follow its README. Running from your own network avoids Discover Profile's shared server IP and may produce more complete results, although local IP reputation, geography, target changes, and service limits still apply.
Open kaifcodec/user-scanner on GitHub01. From query to result
Username and email inputs use separate validation and classification rules, but they follow the same six-stage research path.
- 01 / Input
Submit one identifier
Enter an exact username or a complete email address.
- 02 / Validate
Apply workflow rules
Trim the value and reject inputs that do not meet the selected format.
- 03 / Dispatch
Request one category and page
Choose a configured API endpoint by weight and send a signed scan request.
- 04 / Receive
Keep every returned row
Positive, negative, unknown, and error rows remain visible in the log.
- 05 / Classify
Promote exact positive states
Only
FoundorRegisteredrows become possible-match cards. - 06 / Review
Verify original context
Open the source, compare independent details, and record uncertainty.
The interface is an evidence-organizing layer over returned API data. It does not replace the source and does not turn a technical status into an identity finding.
02. Result status reference
The possible-match area is intentionally narrower than the complete response log. The table below describes how the current browser code treats common response states.
| Workflow and state | Interface treatment | What it can support | What it cannot support |
|---|---|---|---|
Username: Found | Creates a possible-account card and remains in the log | A candidate public route under the source's current response | Identity, ownership, authenticity, or a relationship between accounts |
Username: Not Found | Log only | A negative observation from that check at that time | Permanent absence or absence from every spelling, route, or private area |
Email: Registered | Creates a possible-account card and remains in the log | A registration-style account-context signal | Mailbox delivery, current control, identity, or a public profile URL |
Email: Not Registered | Log only | A negative response from that service check | That the address has no other accounts or public references |
Unknown or another non-positive state | Log only | The row did not satisfy the exact positive rule | A positive or negative account conclusion |
Error, failure, timeout, or exception | Counted as an error row and kept in the log | The check was unsuccessful or incomplete | Anything about whether the account exists |
Status text, reason fields, and extra fields originate in the scan response. Discover Profile does not silently convert a failed request into a negative result.
03. Username search method
The browser trims the submitted value, rejects an empty username, rejects whitespace, and limits the value to 100 characters. The interface asks for the exact handle without the @ symbol.
Configured coverage
Social, Creator, Developer, Creative, Community, Gaming, Entertainment, Music, Learning, Shopping, Donation, Finance, Email, Other, Dating, Political, and Adult.
What becomes a possible match
Only a row whose status normalizes exactly to Found becomes a possible-account card. Cards are de-duplicated by normalized site name and URL. All other returned rows remain available by category in the response log.
When a valid result URL is present, the interface can display a Google-provided favicon and an “Open source” link. The icon and link improve navigation; neither adds evidentiary weight to the result.
04. Email search method
The browser trims the address and requires a complete value with content before and after @ plus a domain suffix. The full address is then checked one configured category at a time.
Configured coverage
Social, Developer, Creator, Community, Shopping, Entertainment, Other, Gaming, Learning, Jobs, Music, Travel, Fitness, Hosting, CRM, News, Sports, Dating, Women's Health, and Adult.
Account context, not mailbox verification
Only a row whose status normalizes exactly to Registered becomes a possible-account card. Many services expose registration signals through account-recovery behavior without revealing an account username or ID. A useful signal may therefore have no direct profile URL.
This workflow does not access the inbox, send an email, test delivery through SMTP, or prove that the address is active or controlled by a particular person.
05. API dispatch, pagination, and progress
- Every scan request includes the identifier, one category, a page number beginning at 1, and
only_found=falseso non-positive rows remain available for review. - When multiple API base URLs are configured, the browser makes a fresh weighted selection for each request. Different categories or later pages can use different endpoints that expose the same response format.
- The browser reads
pagination.has_nextafter every response. Pages within one category remain sequential even when username categories run concurrently. - Reported
scanned_modulesvalues are accumulated against the configured total. The displayed percentage is held below 100% while requests remain, then closes at 100% after all category workers finish and no next page remains. - Each category header updates its site, found, error, and page totals in real time. A
Donemarker appears when the category has no next page or ends with a request error.
The pause control prevents the next page or category request from starting; it does not cancel a request already in flight. Restarting invalidates the earlier run in the interface so late responses from it are ignored. The client does not automatically retry a failed page request.
06. Source failures and uncertainty
External services control their own routes, response behavior, rate limits, regional rules, and anti-automation systems. Discover Profile displays the returned classification but does not independently re-fetch every source or override its rule.
| Condition | Possible interface effect | Responsible interpretation |
|---|---|---|
| Changed route or provider behavior | Stale positive, negative, unknown, or error response | Open the source and confirm the current page state |
| Shared API IP reputation, rate limit, CAPTCHA, regional block, or outage | HTTP 403, error, timeout, failed request, or incomplete category | Leave the check unresolved; do not treat it as absence. Consider a local User Scanner run when appropriate |
| Login page, generic shell, or soft 404 | A technically reachable URL may look like a candidate | Check page content and whether it actually refers to the submitted identifier |
| Private, renamed, deleted, or JavaScript-rendered profile | A real account may be missed or left unknown | A missing card is not proof that no account exists |
| Shared, recycled, copied, or impersonated username | A real page may be attributed to the wrong subject | Compare independent details before linking identities |
07. Evidence and verification
A technical detection error and an identity-attribution error are different. A source can return the wrong kind of page, or it can return a real page that belongs to someone else. Both require human review.
- 01Original source
Current profile, service page, or provider context.
- 02Returned response row
Status, URL, reason, extra data, category, and raw returned fields.
- 03Discover Profile presentation
Possible-match card, counters, progress, and grouped response log.
- 04Purpose-specific human judgment
Corroboration, alternative explanations, authorization, and proportional conclusion.
Do not use one match, one missing result, or one visual similarity as the sole basis for identifying a person or making a consequential decision.
08. Privacy Mode and search history
Standard mode
The application creates a first-party history task before scanning. Exact positive matches can be normalized and saved as they arrive, and the task is marked complete after all category workers finish. Negative, unknown, and error rows remain in the live log and are not saved as positive matches.
Privacy Mode
Privacy Mode is off by default. When enabled before a scan, the browser skips first-party task creation, result saving, and task completion. The configured scan API still receives the username or email address, category, page, and request metadata required to perform the checks.
Third-party requests and deletion
If a valid result URL is rendered, the browser may request a site icon from Google's favicon service. Stored individual history tasks and the current application account can be permanently deleted through the user workspace. See the Privacy Policy for the full data-flow and retention explanation.
09. Re-testing and corrections
Public-source checks age as platforms change. A route, API response, recovery flow, status vocabulary, pagination format, rate limit, or regional behavior can change without a visible change to this website.
To report a false positive, false negative, broken source, outdated category, or incorrect methodology statement, email [email protected]. Include the query type, affected service, observed status, expected behavior, approximate time, relevant public URL, and only the minimum safe reproduction detail. Never send credentials or private mailbox content.