Start Here: How to Use an OSINT Tool Catalog Without Getting Lost

An OSINT tool catalog can save hours of work.

It can also waste them.

The difference is whether you use the catalog as a decision system or as a list of interesting links.

A weak workflow looks like this:

Find an impressive tool → run it → collect output → decide what the output means afterwards.

A stronger workflow reverses the order:

Define the question → identify the signal you need → choose the least intrusive tool that can produce that signal → evaluate the result → decide whether another step is justified.

That sequence is the foundation of OSINT.dev.

The catalog is not designed to tell you which tool is "best."

It is designed to help you answer a more useful question:

Which tool fits this research job, at this stage, with these limits?

---

A catalog is a map, not a trophy shelf

Tool collections often become impressive for the wrong reason.

They accumulate:

• hundreds of links;
• overlapping services;
• abandoned projects;
• tools with unclear pricing;
• products that solve different problems but sit in the same category;
• tools whose outputs look authoritative without explaining their limits.

The result is breadth without decision support.

A useful catalog should reduce uncertainty.

For each entry, you should be able to understand:

• what problem the tool helps with;
• what kind of input it expects;
• what kind of output it produces;
• whether the method is passive or more interaction-heavy;
• what the important limitations are;
• whether the tool is active, deprecated or retired;
• what level of access is required;
• what risk or caution class applies;
• which documentation or articles explain how to interpret the result;
• what you should consider doing next.

Bellingcat's Online Investigations Toolkit was built around a similar problem: researchers need more than a tool name. Its toolkit emphasizes use cases, requirements and limitations so that tool discovery leads to informed use rather than random experimentation.

OSINT.dev follows the same broad philosophy while adding its own taxonomy, access policies, native runners, related articles, linked sources and account history.

---

Start with the research question

Before opening the catalog, write the question in one sentence.

Bad:

I want to investigate this website.

Better:

Has this public website recently migrated to a different domain or platform?

Bad:

I want information about this company.

Better:

Does this company legally exist in the claimed jurisdiction, and which public records identify its officers?

Bad:

Is this image fake?

Better:

Has this image appeared online before, and is there evidence that its current context differs from earlier uses?

Bad:

Is this domain malicious?

Better:

What public reputation, detection and infrastructure signals exist for this domain, and how current are they?

The narrower question immediately improves tool selection.

It also gives you a stop condition.

Without a question, every new result becomes an excuse to collect something else.

---

Turn the question into a signal family

A research question is often easier to solve after translating it into the type of evidence you need.

Think in signal families.

Company and legal-entity signals

Questions include:

• Does the company exist?
• What is the legal name?
• Where is it registered?
• Which officers or entities are connected to it?
• Are sanctions or risk-list signals relevant?

Representative catalog entries include:

• OpenCorporates;
• OCCRP Aleph;
• OpenSanctions.

The first step is usually identity resolution.

Do not begin with sanctions or network graphs if you are not yet sure which legal entity you are looking at.

Domain and infrastructure signals

Questions include:

• Which public hostnames are associated with this domain?
• What does certificate history reveal?
• How has DNS changed?
• Which public services or technologies are visible?
• Does a redirect or infrastructure pattern suggest migration?

Representative tools include:

• crt.sh;
• SecurityTrails;
• Censys;
• urlscan.io;
• OSINT.dev's native DNS, redirect and tech-stack tools.

Start with the narrowest layer capable of answering the question.

Certificate transparency is not the same evidence as historical DNS.

Historical DNS is not the same evidence as a live HTTP response.

Keep the layers separate.

Image and media-verification signals

Questions include:

• Has this image appeared before?
• Does this file contain useful metadata?
• Are there visual anomalies worth investigating?
• Has a related claim already been fact-checked?

Representative tools include:

• TinEye;
• ExifTool;
• Forensically;
• Google Fact Check Explorer.

These tools solve different jobs.

Reverse-image search is not metadata analysis.

Metadata analysis is not manipulation detection.

A fact-check database is not independent verification of every new artifact.

Preservation and evidence signals

Questions include:

• What did this page look like previously?
• How do I preserve what I see now?
• Do I need a local capture, a public archive or an investigative evidence trail?

Representative tools include:

• Wayback Machine;
• SingleFile;
• ArchiveBox;
• Hunchly.

Preservation should happen early when the material may change.

Do not wait until after the page disappears to decide that it mattered.

Threat and artifact-context signals

Questions include:

• Has this file, URL, domain or indicator been seen in security datasets?
• Are there public detections or threat-intelligence references?
• Is this indicator part of a known shared pulse or campaign context?

Representative tools include:

• VirusTotal;
• AlienVault OTX.

Treat these results as context.

A detection count is not a verdict, and a clean-looking result is not proof of safety.

---

Use the catalog filters as research controls

OSINT.dev's public catalog currently supports filtering by:

• macrocategory;
• category;
• risk class;
• status;
• search text.

Those filters should not be used merely to make the list shorter.

They encode different parts of the decision.

Macrocategory

Use the macrocategory when you know the broad research domain but not the exact technique.

Examples:

• company research;
• infrastructure;
• evidence;
• media verification.

This is the right level when the question is still broad.

Category

Use the category when you know the specific signal or method.

For example:

• certificate transparency;
• DNS history;
• reverse image search;
• company registries.

Categories reduce tool-hopping because they put genuinely related methods closer together.

Risk class

Risk is a research constraint, not a quality score.

A "safe" tool is not automatically better than a "caution" tool.

The label tells you that the method deserves a different level of attention around:

• interaction with targets;
• sensitivity;
• data handling;
• operational context.

Choose the lowest-interaction method that can answer the question before escalating.

Status

Status tells you about the catalog entry's lifecycle.

OSINT.dev distinguishes states such as:

• active;
• deprecated;
• retired or removed in the underlying model.

A deprecated tool may still be useful for historical context or compatibility.

It should not silently be treated as the preferred current choice.

Search

Use free-text search when you already know:

• the product name;
• a method;
• an input type;
• a specific research concept.

Do not use search as a substitute for understanding the taxonomy.

If you repeatedly search for a concept and do not know which category it belongs to, the taxonomy itself can help you clarify the problem.

---

Read the tool card before you click

A public OSINT.dev tool card currently exposes several signals before you open the detail page:

• primary macrocategory and category;
• tool name;
• short description;
• status;
• risk class;
• access level.

That is enough to perform a first triage.

Ask:

Does the description match the question?

If not, skip it.

A tool being popular does not make it relevant.

Is the tool active?

If deprecated, check whether a current alternative exists in the same category.

Does the risk class fit the investigation?

If a safer method can answer the same question, use that first.

Can you access it?

Some entries may be public while others can require login, verified email, a higher access level or another gate.

Access policy is part of the method.

---

The detail page is where selection becomes interpretation

Opening a tool should answer more than:

Where is the link?

OSINT.dev tool detail pages can include:

• a longer overview;
• taxonomy and tags;
• status, risk, visibility and access policy;
• documentation;
• related editorial articles;
• related tools;
• linked monitored-source items;
• an interactive native runner when one exists.

The useful workflow is:

read → understand → run or open → interpret → corroborate

not:

run → stare at output

---

Native runners and external tools are different experiences

Some OSINT.dev entries have native interactive runners.

Examples currently include public-surface tools for:

• DNS;
• redirects;
• security headers;
• robots and metadata;
• technology signals.

Other catalog entries point to external services or provide editorial context around them.

Do not assume those two classes are equivalent.

A native runner

A native runner gives OSINT.dev control over:

• input validation;
• output structure;
• access policy;
• safety constraints;
• logging behavior;
• documentation.

But it is intentionally limited to the functionality implemented by that runner.

Read the related guide to understand the scope.

An external tool

An external service has its own:

• data collection;
• account model;
• pricing;
• limits;
• retention;
• legal terms;
• update schedule.

OSINT.dev can review and explain that service.

It does not control the external provider.

Always distinguish:

OSINT.dev's description of the tool

from:

the provider's live functionality and policy.

---

Choose the lightest useful tool

A simple rule prevents a large amount of bad OSINT:

Pick the least intrusive tool that can answer the current question.

Imagine the question:

Did this domain use another hostname in the past?

A sensible first step might be:

• certificate-transparency history;
• historical DNS;
• archives.

It probably does not require:

• broad scanning;
• automated enumeration;
• complex graph expansion.

Imagine instead:

What HTTP security policies does this public page currently advertise?

Use a focused header check.

Do not launch an unrelated infrastructure platform simply because it has more data.

Breadth should be earned by the question.

---

Prefer explainable output over impressive output

Large outputs create a cognitive trap.

A graph with 300 nodes looks analytical.

A report containing 2,000 indicators looks comprehensive.

Neither guarantees relevance.

When comparing tools, prefer the one whose result you can explain.

Ask:

1. Where did this value come from?
2. What time does it describe?
3. Is it current or historical?
4. Is it directly observed or inferred?
5. What does the tool not know?
6. Can another source corroborate it?

If you cannot answer those questions, the output is not yet a finding.

---

One result should create one of five next actions

Every useful tool result should lead to a deliberate next step.

1. Verify

Use another source to test the same claim.

Example:

A company database identifies an officer.

Verify against:

• official registry material;
• filings;
• another structured source.

2. Corroborate

Use a different signal family.

Example:

Certificate history suggests a new hostname.

Corroborate with:

• DNS;
• current HTTP behavior;
• historical web captures.

3. Preserve

Capture the evidence before it changes.

Example:

A page contains an important public statement.

Use an archive or local evidence-capture workflow.

4. Expand

Widen the investigation only if the current evidence creates a specific new question.

Example:

A domain clue suggests a larger infrastructure relationship that is directly relevant to the case.

5. Stop

If the original question is answered to the required confidence, stop.

Stopping is a research action.

It prevents collection from becoming an end in itself.

---

Do not confuse related tools with interchangeable tools

Catalogs naturally place similar tools together.

Similarity does not mean equivalence.

For example:

crt.sh and SecurityTrails

Both can contribute to domain research.

But certificate transparency and historical DNS are different evidence layers.

TinEye and ExifTool

Both may appear in an image-verification workflow.

But reverse-image search and file metadata answer different questions.

Wayback Machine and Hunchly

Both relate to evidence and preservation.

But historical public archives and case-oriented capture workflows solve different operational problems.

VirusTotal and OTX

Both provide security context.

But detection-oriented artifact analysis and shared threat-intelligence context are not the same job.

Comparison articles in OSINT.dev exist to make those distinctions explicit.

Use them.

---

A practical decision matrix

When you are unsure which tool to use first, classify the job.

This is not a ranking of products.

It is a mapping from question to first signal.

After the first result, the appropriate next tool may change.

---

Beginner workflow: six steps

If you are new to OSINT.dev, use this sequence.

Step 1 — Write the question

One sentence.

If the question contains several unrelated goals, split it.

Step 2 — Choose one signal family

Company?

Infrastructure?

Image?

Evidence?

Threat context?

Something else?

Step 3 — Filter the catalog

Use:

• macrocategory;
• category;
• risk;
• status;
• search.

Do not open ten tools yet.

Step 4 — Read two or three candidate entries

Compare:

• purpose;
• limitations;
• risk;
• access;
• related guides.

Then choose one.

Step 5 — Record the result

At minimum:

• target/input;
• timestamp;
• tool;
• observation;
• why it matters.

If the evidence is volatile, preserve it.

Step 6 — Decide the next action

Verify?

Corroborate?

Preserve?

Expand?

Stop?

Do not let the tool decide automatically.

---

Intermediate workflow: build a tool chain

Once the first question is stable, tools can form a deliberate sequence.

Example:

Question

Is this company website connected to the legal entity I identified?

Possible workflow:

1. OpenCorporates — establish legal identity;
2. company website — establish first-party claim;
3. DNS/certificate tools — examine technical public surface;
4. Wayback Machine — compare historical branding or domains;
5. evidence capture — preserve the relevant pages;
6. structured notes — separate facts, inferences and open questions.

Each tool has a different job.

The value comes from the chain, not from any one product.

---

Advanced workflow: automate only after the method is stable

Automation should remove repetition.

It should not replace understanding.

Before automating a workflow, you should be able to explain:

• what the input represents;
• what each source contributes;
• which failures are expected;
• how duplicates are handled;
• which outputs deserve review;
• what confidence means;
• when collection stops.

The Berkeley Protocol emphasizes planning, documentation, preservation, verification and analysis as distinct professional responsibilities in digital open-source investigations.

That logic applies even outside human-rights investigations:

collection is only one part of a defensible research process.

If your manual process is unclear, automation usually scales the confusion.

---

Tool output is not intelligence

A catalog helps you collect evidence.

It does not make the analytical judgment for you.

Keep three layers separate.

Observation

crt.sh contains a certificate entry for sub.example.com.

Hypothesis

The hostname may have been part of the organization's public infrastructure.

Judgment

Historical and current evidence supports the conclusion that the hostname was operated as part of the organization's public service during period X.

The first layer came from a tool.

The later layers require analysis and corroboration.

A good catalog should make that distinction easier to maintain.

---

Beware of tool-centric learning

There is a reason a catalog can become dangerous educationally.

Tools are concrete.

Methods are harder.

It is easy to feel progress because you have learned:

• where to click;
• which field to paste;
• which button to press.

But product interfaces change.

Pricing changes.

APIs disappear.

Services shut down.

A method survives those changes.

Use the catalog to learn:

what type of evidence a tool produces

rather than merely:

how to operate this product.

That habit makes your OSINT capability portable.

---

Evaluate limitations before using the result

Bellingcat's research into investigator needs found that users value transparency around what tools cannot do and become frustrated when products oversell their capabilities.

That is a useful standard.

Before relying on a tool, ask:

• Is the database complete?
• How fresh is it?
• Does the tool cover my jurisdiction?
• Does it show historical or current data?
• Does it normalize entities?
• Is the result user-submitted?
• Does it execute live collection?
• Does it use third-party datasets?
• Are important functions paid?
• Does the method create direct interaction with the target?

A limitation is not necessarily a reason to reject a tool.

It is information you need in order to use the result correctly.

---

Evidence should be reproducible

The Berkeley Protocol treats documentation and preservation as core parts of professional open-source investigation.

For ordinary OSINT, the same principle improves quality.

When a tool result matters, record enough that another person can reconstruct the reasoning.

Useful fields include:

• research question;
• input;
• tool and method;
• timestamp;
• raw observation;
• source URL or record;
• interpretation;
• confidence;
• limitations;
• related evidence.

If the finding cannot be traced back to its source, it becomes progressively less useful.

---

How to read OSINT.dev's access and policy signals

OSINT.dev attaches policy information to tool entries because not every method should be presented as frictionless.

Depending on the entry, you may see information about:

• risk class;
• access level;
• visibility;
• logging;
• status.

These labels describe how OSINT.dev handles the tool or runner.

They do not replace:

• law;
• authorization;
• the external provider's terms;
• professional judgment.

A tool being visible in the catalog is not blanket permission to use it in every context.

---

When the catalog does not contain the tool you need

A curated catalog should not pretend to be complete.

If no entry fits the question:

1. check whether you chose the correct category;
2. reformulate the signal you actually need;
3. search for the method rather than the brand name;
4. consult related articles and sources;
5. use an external tool only after understanding what evidence it produces.

The absence of a tool can also reveal a catalog gap.

A living reference should improve through:

• additions;
• corrections;
• status changes;
• deprecations;
• community feedback.

Completeness is not achieved once.

It is maintained.

---

A worked example

Suppose you receive a screenshot claiming that a company has been sanctioned.

The weak approach is:

Search the company name everywhere and collect screenshots.

A stronger catalog-driven workflow is:

Question 1

Which legal entity does the screenshot refer to?

Start with legal-entity data.

Record:

• exact name;
• jurisdiction;
• registration identifiers.

Question 2

Is that exact entity listed in an authoritative sanctions or risk dataset?

Use a sanctions-focused source.

Check identity carefully.

Do not collapse a similar name into a match.

Question 3

Is the screenshot itself old, altered or taken out of context?

Use image or provenance methods if relevant.

Question 4

What should be preserved?

Capture:

• the original claim;
• the source record;
• relevant dates;
• the exact entity identifiers.

Conclusion

Only after those steps should you write something like:

The public record identifies entity X, registration Y. Source Z lists the same entity under identifier Y as of date D.

The catalog did not produce the conclusion.

It helped structure the path to it.

---

The five-question rule

Before running any tool in the catalog, ask:

1. What question am I trying to answer?
2. What type of evidence could answer it?
3. Why is this tool appropriate for that evidence?
4. What can this tool not establish?
5. What will I do with the result?

If you cannot answer those five questions, do not run the tool yet.

Clarify the method first.

---

Where to go next

After this guide, choose the article that matches your immediate job.

Company research

Read:

A Responsible Method for Company Research with Public Sources

Domain and infrastructure work

Read:

A Practical Method for Domain and Infrastructure Recon

and the reference guides covering:

• DNS;
• redirects;
• security headers;
• metadata;
• technology fingerprints.

Evidence handling

Read:

Building a Lightweight Evidence Capture Workflow

Workflow design

Read:

Choosing Between Manual, Semi-Automated and Automated OSINT Workflows

Research discipline

Read:

A Responsible Method for Reconnaissance on Public Web Surfaces

and:

How to Turn Weak Signals into Better Questions

The catalog becomes more useful when it sits inside a method.

---

The core principle

The purpose of an OSINT tool catalog is not to help you run more tools.

It is to help you make fewer, better tool choices.

Use this sequence:

question → signal → category → candidate tools → limitations → smallest useful action → observation → corroboration → stop or expand

That is the difference between browsing a catalog and using one as research infrastructure.

OSINT.dev should make that reasoning visible.

The tool is not the investigation.

The tool is one controlled step inside it.

---

References

Authoritative and practitioner references supporting the approach in this guide:

• OHCHR / Human Rights Center, UC Berkeley — Berkeley Protocol on Digital Open Source Investigations
  https://www.ohchr.org/sites/default/files/2024-01/OHCHR_BerkeleyProtocol.pdf

• Human Rights Center, UC Berkeley — Developing the Berkeley Protocol on Digital Open Source Investigations
  https://humanrights.berkeley.edu/projects/developing-the-berkeley-protocol-on-digital-open-source-investigations/

• Bellingcat — Find the Right Open Source Research Tools With Bellingcat's Online Investigations Toolkit
  https://www.bellingcat.com/resources/2024/09/24/bellingcat-online-investigations-toolkit/

• Bellingcat — First Steps to Getting Started in Open Source Research
  https://www.bellingcat.com/resources/2021/11/09/first-steps-to-getting-started-in-open-source-research/

• Bellingcat — OSHIT: Seven Deadly Sins of Bad Open Source Research
  https://www.bellingcat.com/resources/2024/04/25/oshit-seven-deadly-sins-of-bad-open-source-research/

• Bellingcat — These Are the Tools Open Source Researchers Say They Need
  https://www.bellingcat.com/resources/2022/08/12/these-are-the-tools-open-source-researchers-say-they-need/