Sherlock: username search across 400+ social networks

What Sherlock actually does with a username

Give Sherlock a username and it asks a few hundred public sites whether that name exists there. The README frames the project as hunting down social media accounts by username across 400+ social networks, and the site list is published at sherlockproject.xyz/sites. The output is a plain text file named after the username, for example user123.txt, plus optional CSV, XLSX or JSON depending on flags. That is the whole product. It is aimed at OSINT and reconnaissance work, which pyproject.toml lists under keywords alongside information gathering, and at developers who want a scriptable check rather than a browser.

The important framing is negative. A hit means a page responded in a way Sherlock reads as an existing account. It does not mean the account belongs to the person you are investigating, and a miss does not mean the person has no presence on that platform. Username reuse is common, and plenty of people use different handles per site. Treat the file as a list of candidates to open and verify by hand.

How the checks run: futures, timeouts and proxies

The dependency list in pyproject.toml is the clearest description of the mechanism. requests handles HTTP, requests-futures runs those requests concurrently instead of one at a time, PySocks adds SOCKS proxy support, stem points at Tor control, certifi supplies the CA bundle, and pandas with openpyxl produce the spreadsheet exports. colorama and tomli cover terminal colour and config parsing. There is no browser engine and no JavaScript execution anywhere in that list, so Sherlock sees only what a plain HTTP client sees.

Concurrency is why the tool finishes in a reasonable time despite checking hundreds of hosts, and it is also why a single run produces a burst of traffic from your address. The --timeout flag exists because per-site latency varies; a short timeout trades slower sites for a faster run and more false negatives. --proxy PROXY_URL and the Tor-related dependency exist for the same reason: to move that burst somewhere else. Because everything is HTTP-level, sites that render account pages client-side, gate them behind a login, or block datacentre IPs will not be checked usefully. The repository keeps its site definitions in the sherlock_project package, and the tests directory plus pytest.ini and tox.ini suggest the project validates those definitions rather than trusting them.

Installing Sherlock and running a first search

The README recommends pipx, with pip or uv as substitutes, and warns that third-party packages for ParrotOS and Ubuntu 24.04 appear broken. Users on those systems are told to defer to uv, pipx, pip or Docker. The simplest supported path is pipx:

pipx install sherlock-project

After that, the binary is on your PATH. The README's first example searches a single username:

sherlock user123

Accounts found are written to an individual text file named after the username, so you should end up with user123.txt in the working directory. If you would rather not install Python packages at all, the README gives a Docker one-liner:

docker run -it --rm sherlock/sherlock

Fedora users have a distro package as well:

dnf install sherlock-project

For several names at once, pass them as separate arguments. The README shows sherlock user1 user2 user3, and notes that the positional argument accepts {?} to check similar usernames. Run sherlock --help to see the full flag set, which includes --site to limit the run to named sites, --csv, --xlsx and --json for structured output, --print-found or --print-all to control console noise, --no-color, --browse, --local, --nsfw, --txt, --ignore-exclusions, --dump-response, --folderoutput and --output. On Kali, the search questions people ask are about the same commands; the upstream README does not document a Kali-specific workflow, so the pipx or Docker route above is the one the project itself supports.

Where the results mislead you

The failure modes are mostly about what a hit means. Some sites return a page for any username, so a naive check reports an account that does not exist. Some return a login wall or a rate-limit page, which can look like either a hit or a miss depending on how the site definition interprets it. --dump-response exists precisely because you sometimes need to see the raw reply and judge for yourself. If you never use it, you are trusting a definition you have not read.

Volume is the second problem. Checking hundreds of hosts concurrently from one IP is a recognisable pattern, and sites that care will throttle or block it. --proxy and the Tor support in the dependency list are the project's answer, but routing OSINT traffic through Tor changes how sites respond and can itself be blocked. --nsfw and --ignore-exclusions matter here too: the site list includes adult and excluded entries, and the defaults are a choice you should understand before running the tool against a name at work.

Finally, Sherlock is the wrong tool for depth. It will not read a profile, correlate posts, resolve a real identity, or search inside a platform's own search index. It answers one narrow question, and the answer is a URL list.

Sherlock versus writing your own checker

The obvious alternative is a short script of your own: a list of URLs, a loop with requests, and a rule for what counts as existing. That is genuinely what Sherlock is underneath, and if you only care about five sites you control, your own script is easier to reason about, has no dependency on someone else's site definitions, and will not surprise you with a 400-host burst.

The difference is maintenance. Sherlock's value is the maintained catalogue of site definitions and the parsing rules that go with them, plus the export formats and the concurrency and proxy plumbing already wired together. Sites change their account URLs and response codes constantly, and keeping hundreds of definitions current is the part nobody wants to own. If your target set is small and stable, build the script. If your target set is the long tail, the catalogue is the reason to use Sherlock, and you should expect to update it often.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2025-09-16, the same date as the v0.16.0 release. The previous release, v0.15.0, is dated 2024-07-08, so the gap between them is roughly fourteen months. pyproject.toml declares version 0.16.2, which is ahead of the v0.16.0 tag, so the packaged version and the release tag are not identical; check which one you installed. The classifiers list Python 3.10 through 3.13 while the dependency constraint says python = "^3.9", and the Dockerfile builds on python:3.12-slim-bullseye.

Upgrade cost is mostly the site catalogue. Because the tool's usefulness depends on definitions matching live sites, a stale install degrades quietly: it still runs, it still prints results, and the results get worse. Pin a version if you need reproducibility, but plan to refresh regularly. The licence is MIT, which is permissive and places few obligations on reuse; the project also carries a third-party package warning for ParrotOS and Ubuntu 24.04, and community packages for Debian, Ubuntu, Homebrew, Kali and BlackArch are explicitly described as not directly supported or maintained by the Sherlock Project. Those are packaging questions, not licence questions, and they are the ones most likely to bite you on a distro install.

Who should run Sherlock and who should not

Use it when you have a username, a list of candidate platforms, and a need for a quick scriptable sweep whose output you will verify manually. The text-file-per-username default, the CSV, XLSX and JSON exports, and the --site filter make it easy to slot into a larger pipeline, and the MIT licence removes friction for internal tooling.

Do not use it as evidence. A Sherlock hit is a URL that responded; it is not attribution, and it is not a substitute for opening the profile. Do not use it where you need authenticated or private data, since every check is an unauthenticated HTTP request. Do not run it from an address you cannot afford to have rate-limited or blocked, and do not assume the distro package is current. If you are on ParrotOS or Ubuntu 24.04, take the README's warning seriously and install via pipx, uv, pip or Docker instead.

Editorial conclusion

Adopt Sherlock if you need a quick, scriptable first pass over a username and you are comfortable treating the output as leads rather than evidence. Skip it if you need platform-specific depth, private or authenticated data, or a tool that will not touch a few hundred sites from your IP. Before you rely on it, check the broken-package warning for ParrotOS and Ubuntu 24.04, confirm the version installed by your package manager matches the release you expect, and read the site list to see whether the platforms you care about are even covered.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes