Sherlock OSINT: Install It, Run It, and Know When It Isn't Enough

Sherlock OSINT is a free, open-source tool that takes one username and checks it against several hundred websites (social networks, forums, developer platforms, blogging sites) to report where an account with that exact handle exists. You install it with pipx or Docker and run it from a terminal as sherlock <username>. It answers a single narrow question well: where is this username registered. It does nothing else. No breach data, no email or phone pivots, and no verification of what it finds. This guide covers installation, the flags worth memorizing, where the tool breaks, and when a broader platform is the better instrument.

What Sherlock actually does

Sherlock lives at github.com/sherlock-project/sherlock and is a community-maintained Python project. The mechanism is simple enough to read in an afternoon. The repository ships a JSON file mapping sites to URL templates plus expected "found" and "error" responses. You supply a username. Sherlock requests https://<site>/<username> for every entry, compares each response against those signatures, and prints the sites where the handle resolves to an account.

That transparency is why I still reach for it. Every check is auditable. There is no account to create, nothing to sign, and results are reproducible on any machine with a Python runtime. For a quick "does this handle exist anywhere obvious" pass, the cost-to-information ratio is hard to beat.

Be equally clear about what it does not do:

• Existence only. A hit is a URL. No profile contents, no creation dates, no follower counts, no linked emails. You still have to open each account and read it.
• One vector. Usernames only. Give it an email address or a phone number and it has nothing to say.
• No breach data. If an account's credentials showed up in a breach dump or an infostealer log, that is a different dataset, and Sherlock never touches it.
• No triage. Confirmed accounts, soft matches, and outright false positives arrive in one undifferentiated list.

I treat a Sherlock run as a first pass, not a finished picture. The output is a pile of URLs to open, not a report you can hand anyone.

Installing Sherlock

The recommended install is pipx, which keeps Sherlock's dependencies in their own environment instead of your system Python:

pipx install sherlock-project

One naming trap: older tutorials say pip install sherlock. The maintained PyPI package is sherlock-project, and the short name does not reliably resolve to this project. Use the full name. pipx itself is the standard tool for this kind of CLI app, and it is worth having around regardless.

If you prefer containers, the project publishes a Docker image (as of writing; check the README, the tag has changed before):

docker pull sherlock/sherlock
docker run --rm -t sherlock/sherlock johnsmith

Requirements are light: a current Python 3 (3.8 or newer at time of writing) and a handful of libraries the installer pulls automatically. Verify the install with sherlock --version before doing anything else. If that command is missing, you installed the wrong package or your PATH never picked up pipx's bin directory. Fix that first. Debugging a "scan" that never actually ran is a waste of an afternoon.

Running your first scan

The basic invocation is as plain as it looks:

sherlock johnsmith

Sherlock walks the full site list, printing each found account and its URL as it goes. Older versions wrote results to accounts.txt by default; current behavior leans on explicit --output. Run sherlock --help on your installed version and script against what you actually see there, not against blog posts, this one included.

Two things I wish someone had told me before the first run:

• A full sweep of several hundred sites takes minutes, not seconds. The per-site timeout is the setting that most changes runtime. Leave it alone until you have watched one complete pass and know where your network actually stalls.
• For batches of usernames, loop the CLI per username from your shell. Multi-username invocations have come and gone between releases; confirm with --help before depending on them.

Do not start with a celebrity handle "just to see." Pick a username you already know exists on three or four platforms and check whether Sherlock finds those. If it misses GitHub or Twitter/X on a handle you can see in a browser, your install, network, or site list is the problem, not the target.

The flags worth memorizing

You will use a small subset of Sherlock's options for almost every real run:

• --print-found suppresses the sites-not-found noise and prints only hits. Learn this one first.
• --timeout <seconds> is the per-site timeout. Raise it on slow or distant networks; lower it when you only care about major platforms and want the run finished fast.
• --site <name> restricts the scan to named sites (comma-separated). Use it to re-check a single hit or to split a large scan into chunks.
• --output <file> writes results to disk. Do this for anything that might end up in a report. Terminal scrollback is not evidence.
• --nsfw includes adult-platform checks, which are excluded by default.
• --proxy <url> and --tor route requests through a proxy or Tor. Relevant when your investigation must not present your own IP address to hundreds of sites in the space of minutes.
• --verbose dumps per-site diagnostics when one specific check misbehaves.
• --no-color gives you plain output for logs and pipes.

Output-format flags (JSON, CSV, and similar) have moved between releases. Confirm what your version offers before building automation around them.

One OPSEC note that belongs in every Sherlock guide: the default run fires requests at several hundred sites from your own IP within minutes, a distinctive pattern that some platforms correlate. For authorized investigations where attribution matters, choose your proxy strategy deliberately and rate-limit batch runs. The flip side matters just as much. This is a tool for identifiers you are entitled to investigate, within platform terms and local law.

I keep a short wrapper around the flags I actually use (--print-found, --output, a sane timeout) so I am not re-deriving the invocation every time. The rest of --help is there for the odd site that misbehaves.

Where Sherlock breaks

False positives are routine. Some sites answer every request with HTTP 200 and a generic page: catch-all routing, parked domains, sign-up funnels that render for any path. Sherlock's detection signatures are community-maintained and lag behind site redesigns, so a phantom hit is a normal event, not an anomaly. The working rule is simple. Every hit is a lead until you have opened the URL and confirmed the account. Cross-checking suspicious hits against WhatsMyName, whose site list is curated specifically for detection quality, filters out most phantoms.

Not found is not proof of absence. The failure runs both directions. Stale site entries, silent rate limits, and aggressive timeouts all produce false negatives. A clean Sherlock run establishes only that Sherlock's current site list did not resolve the handle. It does not establish that the username is unused anywhere.

Exact-match only. johnsmith, john_smith, and johnsmith92 are three different usernames, and most people vary their spelling across platforms. A single sweep under-reports badly if you don't run deliberate variants. I keep a short list of mutations (underscores, trailing digits, first-last concatenations) and run those as a second pass, not as an afterthought.

Nothing behind a login. If a profile requires authentication to view, Sherlock's anonymous request learns nothing about it. Sites that gate content will simply look like misses. Do not confuse "Sherlock didn't see it" with "it isn't there."

No breach correlation. Knowing where a handle is registered tells you nothing about whether the account behind it was compromised. Breach dumps and infostealer logs are separate datasets entirely.

The last two gaps are the ones that actually stall a case. A username investigation that stops at "these 30 sites have this handle" usually leaves the actual questions unanswered: who owns it, what else they own, and whether their credentials are already in circulation.

Sherlock next to other username checkers

Sherlock is one of several tools in the same niche, and they have genuinely different strengths:

These stack rather than compete. Sherlock (or Maigret, when coverage matters more than speed) for CLI sweeps you fully control. WhatsMyName to sanity-check anything surprising. A platform like Revealer's username search when the case needs to move past a single handle without standing up a local toolchain.

I still start a lot of username work in Sherlock because I can see every request. I do not stay there once the handle has to become a person.

When one username isn't the whole picture

Real cases rarely hand you a clean, unique handle and ask where it's registered. An impersonation report gives you a sockpuppet and asks who runs it. A compromised-account investigation gives you one handle from a credential dump and asks what else the victim owns. Brand protection gives you a squatter and asks for everything attached to them. In each case the username is the entry point, and the questions expand immediately: what email is behind the account, whether it appeared in a breach, what phone number or name is linked to it.

That expansion is identifier pivoting, and a CLI checker runs out of scope right there:

• Start from any identifier. Revealer's username search takes the same input Sherlock does and checks it against 800+ platforms plus public records and known breach datasets, with no install and no Python environment to maintain.
• Pivot to email. Handles are frequently email prefixes, and email registration data surfaces accounts a username sweep never sees. email lookup starts from that side.
• Let recursion do the chaining. AI Deep Search is the agent-driven version of this work: it follows identifiers across sources, linking username to profile to email to breach exposure in one pass instead of you running each pivot by hand.
• Close the loop with breach-side data. Reverse phone lookup and data breach lookup cover the datasets Sherlock doesn't carry, and infostealer-log search addresses the credential-theft side directly.
• Automate it when it's a workflow. If username triage is a recurring part of your process rather than a one-off, the API makes it scriptable. Plans start free with paid tiers from $12.99/mo and custom Enterprise options (pricing).

One boundary applies no matter which tool you use: Revealer is not a consumer reporting agency, and its data must not be used for employment, tenant, or credit screening. That's the FCRA line, and lawful OSINT work stays on the right side of it.

Frequently asked questions

Is Sherlock free?

Yes. Open-source, no account, no per-search cost. What you spend is time: verifying hits, weeding out false positives, and running spelling variants.

Does Sherlock search by email or phone number?

No. It checks one username against its site list. Email- and phone-anchored searches need different tooling. email lookup and reverse phone lookup both start from those identifiers.

Why does Sherlock report sites that don't exist?

Detection signatures lag behind site redesigns, and some sites return a success page for any username. Treat every hit as a lead and open the URL before acting on it.

Is using Sherlock legal?

Running the tool isn't the issue; what you do with results is. Researching accounts connected to an authorized investigation, defensive work, or your own footprint is standard practice. Harassment, stalking, or targeting people who haven't consented is not, and platform terms of service add their own constraints.

What's better than Sherlock?

It depends which limit you're hitting. Wider site coverage: Maigret. Cleaner verification: WhatsMyName. Breach data, identifier pivoting, and results without a local toolchain: a platform like Revealer.

Does Sherlock check breach or infostealer data?

No. It performs existence checks on live sites only. Breach dumps and infostealer logs are separate datasets, covered by data breach lookup and stealer log search.