More than 400 sites turn one username into a useful lead list
Sherlock takes a username, checks it against more than 400 social networks, and writes the matching profile URLs. The command can accept several usernames, restrict the run to named sites, use a proxy, open results in a browser, and export text, CSV, XLSX, or JSON. That is enough for the first pass of an OSINT investigation without forcing you into a hosted account or browser extension.
The tool answers a narrow question: does a site respond as though this username has a profile? It does not prove that the same person controls every matching account. A common handle can belong to unrelated people, while a service can return a convincing page for a profile that does not exist. Treat the output as a queue of URLs to inspect, not a joined identity record.
A 400-site catalog also creates 400 moving failure points
Each target needs a rule that separates an existing account from a missing one. Those rules age whenever a site changes its URL, error message, redirects, or bot protection. Open issue 3147 asks for an audit of Russian domains that appear to accept arbitrary profile slugs. Issues 3125 and 3126 report a parked page and a soft error page being counted as matches.
Our failed live-target test shows the same practical limit from another angle. The test expected an AllMyLinks account to be classified as claimed, but Sherlock returned a WAF status. The log proves only that the observed response did not match the expected classification. It does not say whether AllMyLinks changed its protection, the request was blocked for another reason, or the test fixture needed an update.
That uncertainty is manageable for a person reviewing twenty leads. It is risky in an automated screening system. A reported profile needs a direct page check and, for serious work, corroborating details such as a matching bio or linked domain. An absent result also needs caution: issue 3121 demonstrates that a dead proxy or mass timeout can produce the same default summary as a genuine search with zero matches.
What happened when we ran it
Our sandbox installed commit e40a45e in 38 seconds, pulling 48 packages and occupying 148 MB. The build succeeded in 6 seconds. We used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Pip-audit reported 0 known vulnerabilities. The repository checkout contained 56 files and about 2,209 lines of source.
Pytest failed after 24 seconds. Of 25 tests, 22 passed, 1 failed, and 2 produced collection/setup errors. The single failure was TestLiveTargets::test_known_positives_via_message[AllMyLinks-blue]: Sherlock returned QueryStatus.WAF where the assertion expected QueryStatus.CLAIMED. The two errors came from tests/test_manifest.py and tests/test_validate_targets.py.
The supplied log tail does not contain the underlying exceptions for those two errors, so blaming a missing package or broken code would go beyond the evidence. The fair result is that install and build worked, while the complete suite did not. Four CI workflow files, a Dockerfile, and a tests directory give maintainers places to catch regressions, but they do not turn our red run green.
Installation is simple if you avoid the broken system packages
The README offers pipx install sherlock-project, with pip and uv as alternatives, plus the sherlock/sherlock container image. It explicitly warns that third-party packages for ParrotOS and Ubuntu 24.04 appear broken. Community packages also exist for Debian 13 or newer, other Ubuntu releases, Homebrew, Kali, BlackArch, and Fedora through dnf, but Sherlock does not maintain most of them.
A basic query needs no hosted API key. The operational dependency is the public web itself: hundreds of outbound requests, site-specific response rules, timeouts, and sometimes WAF behavior. The --local option pins the bundled data file rather than retrieving current target data, while --json can load another local file, URL, or upstream pull request. Pinning the catalog improves repeatability but may preserve stale checks.
Export flags have open edge cases that matter in batch jobs
Sherlock's output choices look straightforward until a script depends on exact paths. Issue 3118 says --csv and --xlsx ignore --output; issue 3115 says XLSX ignores --folderoutput and writes to the current directory. Issue 3119 reports that an unwritable output path raises a raw traceback and stops later usernames from being queried. Those reports were open when we checked them.
There is also an open report about wildcard expansion overwriting one output file. The {?} syntax expands a username into _, hyphen, and period variants, but issue 3114 says a single --output path retains only the last variant. If results feed another system, test the precise combination of formats, folders, and wildcard input you plan to run. Default per-username text output is the less surprising path.
The October 3 push matters more than the modest release note
GitHub showed 93,202 stars, an MIT license, and 356 combined issues and pull requests on October 4, 2026. The repository was pushed on October 3. Version 0.16.2 was released on September 8 with a short note saying several minor changes had accumulated. The recent push and active issue updates show ongoing work even though that release description offers little upgrade guidance.
Sherlock earns a place in a human-led investigation because it makes a tedious public check fast and inspectable. The same design prevents it from being final evidence: every target can change independently, and failure can resemble absence. Our 22 passing tests show most of the checked behavior worked in the sandbox; the WAF mismatch and 2 setup errors are the reason to keep a person between Sherlock's output and any conclusion.