The OSINT Framework, Explained (and What to Use Instead)

An OSINT framework is a structured way to organize open-source intelligence work by identifier and source type. The best-known example, the OSINT Framework at osintframework.com, is a free, browser-based directory of hundreds of external tools and sources arranged in a category tree (usernames, emails, domains, IPs, social networks, and more). It points you to the right resource. It does not run the query. Created by analyst Justin Nordine, it indexes links rather than returning data, so investigators still open each resource separately and merge results by hand.

Index versus platform is the whole story. Hold that, and you already know what the tool is good at, where it fails, and when to pick up something else.

What is the OSINT Framework?

The OSINT Framework launched in the mid-2010s as Justin Nordine's curated index of OSINT resources and grew into one of the most-referenced starting points in the field. It is a single web application that presents hundreds of tools and sources as a collapsible tree. Top-level branches roughly match the identifier or data type you start from:

• Username: tools for locating accounts registered under a given handle across networks
• Email Address: breach checks, account-existence checks, related-address discovery
• Domain Name: WHOIS, DNS history, subdomain enumeration, passive DNS
• IP Address: geolocation, ASN lookup, reputation data
• Social Networks: platform-specific search and extraction utilities
• Search Engines: general and specialized engines, plus advanced search-operator references
• Forums, Blogs, and Archives: including cached and historical copies of pages
• Dark Web: monitoring resources and indexes (use judgment and a lawful purpose here)
• Supporting categories: threat intelligence, geolocation tools, language translation, and metadata utilities for specific case types

Click a leaf node and the site hands you an external link. No account, nothing to install, nothing to pay. A visual mind-map of the same tree still circulates and shows up in training decks more often than any live query tool.

What the OSINT Framework is — and is not

Treat it as a bibliography, not a laboratory. It tells you what exists and where it lives. It does not do the work.

What it is:

• A curated, categorized link list of OSINT tools and sources
• A community touchstone that most OSINT courses and playbooks reference early
• A coverage map: a fast way to ask "what source category have I not checked yet?"

What it is not:

• Not a search engine. There is no query box that returns results against its corpus.
• Not a data platform. Nothing is fetched, normalized, or stored on your behalf.
• Not an aggregator. Ten tools means ten separate tabs, ten output formats, and a manual merge in your notes.
• Not an API. You cannot wire it into a pipeline, a cron job, or a monitoring workflow.

Spend real time with it and the pattern is already familiar: open the Framework, pick a branch, open four links in new tabs, and find that two are dead, one moved behind a paywall, and one works. The value is real. It is the value of a map, not a vehicle.

Where the Framework earns its keep

None of that is a reason to stop using it. For a handful of jobs it is still one of the best resources available.

Onboarding. I still send new hires here on day one. Not because they will run cases from it, but because the tree teaches the shape of the work faster than a slide deck. One page and you see that investigations start from identifiers (username, email, domain, IP, phone) and that each identifier has its own ecosystem of tools. That mental model is worth more than any single tool on the list.

Coverage checks. Midway through a manual investigation, glance at the relevant branch and you get a straight answer to "what did I miss?" If you have been working email-address tools, the branch reminds you that archive caches, paste-site indexes, and breach datasets exist, and whether you actually checked them.

Niche discovery. Specialized branches (language tools, document metadata, geolocation, regional search engines) surface resources a general web search will never rank. When a case demands a niche capability, this is often the shortest path to it.

Zero friction. Free, browser-based, no signup. Teaching, workshops, quick references: nothing about it slows you down.

Where it falls short in real investigations

Every limit traces back to the same fact: links, not data. In practice that produces six recurring problems.

1. Staleness. Tools die, domains change hands, projects get abandoned, and free tiers become paid. An index is only as fresh as its last update, and the update cadence varies, so treat every link as unverified until you click it. Anyone who has used the Framework for a few years has a private list of replacements for the dead entries.

2. Every node is an errand. The Framework does not answer questions. It assigns tasks. Each resource it points to must be visited, learned, queried, and interpreted on its own. Correlating what you find is entirely yours.

3. No aggregation. A typical identifier investigation touches a dozen sources. With a link index that means a dozen sessions, each with a different interface, rate limit, and output format, merged by hand. The merge is where cases slow down and details get dropped.

4. No persistence or monitoring. It has no memory. It cannot tell you when a username appears on a new platform, when an email shows up in a fresh breach, or when anything changed between this week and next. Recurring checks mean walking the same tour again.

5. Breadth backfires under a deadline. Hundreds of links sound like an asset until you are mid-case. For any single identifier, most of the tree is irrelevant, and deciding which three of forty tools matter is itself an investigation.

6. No automation. There is no API and no machine-readable feed. Teams that need OSINT as a repeatable step inside a larger workflow (fraud review, brand protection, threat intel triage) cannot plug a link index into that loop.

I have watched analysts burn an afternoon walking the Email branch, then paste six screenshots into a case note that still does not answer whether the address is the same person. The index did its job. The job was never "answer the question."

How it fits in a real workflow

Say your brand team finds an account impersonating the company, and you start from the username. The Framework's Username branch points you at account-checking tools such as Sherlock, which you can run locally:

pipx run sherlock <username>

Sherlock sweeps a list of social networks for accounts matching the handle and returns the hits. The Email branch then points you at breach-check sites and account-existence tools like holehe. If the impersonator runs a site, the Domain branch covers the infrastructure side. Each step works. Each step is manual, and every result lands in a notes document you maintain by hand.

For a single case once a quarter, that workflow is fine, and it is nearly free. The pattern breaks the moment the work becomes recurring: the same five lookups, every week, against tools whose availability you re-verify each time. Mature shops settle the split. The Framework stays as the coverage map and the niche-tool finder. Repetitive identifier lookups move to maintained tooling.

The hosted alternative: one query instead of forty tabs

The gap the Framework leaves is actual querying, aggregation, and persistence. That is what a hosted platform is built for. Revealer's OSINT toolset is designed around that job: one search by email, username, phone number, name, or address checks 800+ platforms, public records, and known breach datasets, and returns the results together instead of as forty browser tabs.

Mapped against the Framework's busiest branches:

• Email lookup and username search cover the two most common starting points in the tree. One query each, instead of a tour of single-purpose sites and scripts.
• Data breach lookup checks known breach datasets alongside the platform results, so compromise history surfaces in the same pass as account presence.
• Stealer-log search reaches compromise data that link indexes rarely point to at all: credentials and records harvested by infostealer malware.
• AI Deep Search is the recursive option: agent-driven people intelligence that follows identifiers across sources, chaining the hops you would otherwise assemble by hand, tab by tab.

A link index cannot offer automation. Revealer provides API access, which is what makes the workflow repeatable for teams. Breach monitoring covers the recurring-check case the Framework has no answer for. There is a free tier to start; self-serve paid plans begin at $12.99/month, with custom Enterprise arrangements, and both card and crypto payments are accepted. Details on the pricing page and integration notes in the API documentation.

One boundary, because it comes up in every people-search conversation: Revealer searches public records and public data sources. It is not a consumer reporting agency, and its results are not for use in employment decisions, tenant screening, credit decisions, or any other FCRA-covered purpose.

OSINT Framework vs. Revealer

These are different jobs, not rivals. One is a map of the territory. The other is a vehicle for driving it daily. Most practitioners keep both.

Which should you use?

A quick decision guide:

• You are learning or teaching OSINT. Use the Framework. No resource maps the discipline faster, and understanding the category tree is foundational.
• You need one obscure capability (a regional archive, a language tool, a niche metadata extractor). Use the Framework. Its breadth is the point, and the obscurity is where it shines.
• You investigate identifiers regularly (email addresses, usernames, phone numbers) and need results you can hand to someone else. Use a hosted platform. The manual tour stops paying for itself after the first few cases.
• You need breach exposure checks or ongoing monitoring. Use a hosted platform. A link index has no memory; Revealer's breach and monitoring tools are built for exactly this.
• You are building OSINT into a pipeline. Use an API. The Framework has none; the Revealer API exists for this case.

The people who get the most out of the OSINT Framework are the ones who treat it as a starting point rather than a workflow. Read the tree to understand coverage, keep it for the niches, and let maintained tooling carry the repetitive work.

Frequently asked questions

What is the OSINT Framework? A free, web-based directory of OSINT tools and sources organized as a branching category tree. Justin Nordine built it as a link index. It does not run searches or return data itself.

Is the OSINT Framework free? Yes. Browser-based, no account, no cost. The individual tools it links to set their own pricing and terms, which is part of why you verify every link before you rely on it.

Who created the OSINT Framework? Justin Nordine, an OSINT practitioner and instructor. The project launched in the mid-2010s and became a standard first reference in OSINT courses and playbooks.

Does the OSINT Framework perform searches? No. It is a link index. You use each listed resource separately, and you correlate results across them yourself.

Is the OSINT Framework still maintained? It receives updates, but cadence varies, and stale links are the complaint you will hear first from anyone who uses it weekly. Treat every entry as unverified until you click it, and keep your own replacements for the dead ones.

What is the best OSINT Framework alternative? For recurring identifier lookups, a hosted platform is the practical upgrade: one query by email, username, phone, name, or address against 800+ platforms, public records, and breach datasets, with API access for pipelines. See the full Revealer OSINT toolset or start with a people search.