Hunchly vs ArchiveBox: Evidence Packaging vs Archive Ownership

Hunchly and ArchiveBox can both preserve web material.

That superficial similarity makes them easy to compare incorrectly.

They are not simply:

two ways to save webpages.

They are built around two different operational problems.

A useful distinction is:

Hunchly is investigator-first: capture, organize, hash, sign, annotate and report the web evidence encountered during a case.

ArchiveBox is archive-first: ingest URLs into a self-hosted collection, preserve them in several formats, manage the collection and repeat the process over time.

Both can be part of a serious evidence workflow.

But they optimize different layers of that workflow.

The right question is therefore not:

Which preservation product is better?

It is:

Do I primarily need to document an investigation, or do I primarily need to operate an archive?

---

The short answer

Use Hunchly first when:

• an investigator is actively browsing;
• capture should happen as part of the research session;
• URL, timestamp and evidence context must stay tied together;
• notes, tags and case organization matter;
• evidence hashing/signing and reporting are part of the workflow;
• the investigative trail itself may need later review.

Use ArchiveBox first when:

• you have many URLs to preserve;
• repeat ingestion matters;
• you want self-hosted custody;
• you want several redundant capture formats;
• preservation is becoming persistent infrastructure;
• you need an archive that survives beyond one investigator's browsing session.

Use both when:

Hunchly documents the case and ArchiveBox preserves a broader controlled collection around important targets.

---

Comparison at a glance

The two products overlap.

Their center of gravity is different.

---

Hunchly: the investigation is the organizing unit

Hunchly's current product language is explicit:

capture, organize and preserve information from online research.

The key word is not only "capture."

It is research.

Hunchly automatically records information such as:

• URL;
• timestamps;
• hashes;
• page captures;

as the investigator browses.

It then keeps those captures connected to an investigative workflow involving:

• cases;
• tags;
• notes;
• review;
• reporting;
• audit trail.

This makes Hunchly fundamentally different from a generic archive queue.

The primary unit is:

the investigator's evidence trail.

---

Hunchly reduces the "I forgot to save it" problem

Manual evidence capture fails because investigators are busy thinking.

A typical sequence becomes:

open interesting page
↓
follow link
↓
open another source
↓
compare details
↓
realize the first page changed
↓
discover no proper capture exists

Hunchly is designed to reduce this friction by making capture part of the browsing workflow.

Its current product describes automatic collection of:

• page URL;
• timestamps;
• hashes;
• full-page captures.

That changes investigator behavior.

Instead of:

remember to preserve important pages later

the workflow becomes closer to:

preserve the browsing trail as the investigation develops.

---

Hunchly's evidence model includes more than screenshots

Hunchly's current Evidence Guide explains that web pages are stored as MHTML captures.

MHTML packages page content and related resources into a single file structure generated by Chrome.

Hunchly then associates additional evidence controls around the capture.

The current guide documents:

• MHTML page captures;
• SHA-256 hashing;
• GPG signing;
• deletion logging;
• evidence validation considerations.

This is why calling Hunchly:

a screenshot tool

would substantially understate the product.

A screenshot may be useful for presentation.

The underlying evidence model is richer.

---

MHTML preserves a different layer from a screenshot

A screenshot primarily preserves a visual representation.

An MHTML capture can preserve:

• page content;
• layout-related resources;
• links;
• metadata included in the packaged representation.

Hunchly's documentation explains that Chrome handles the MHTML capture and includes metadata such as:

• original content location;
• subject/title;
• capture date.

This does not make MHTML a perfect forensic record of every browser/network event.

It gives the investigator a portable representation of the captured page with more structure than a simple screenshot.

---

Hunchly hashes captured evidence

The current Hunchly Evidence Guide states that Hunchly automatically hashes:

• MHTML files;
• photos;
• attachments;

using SHA-256 before storage.

This is useful for later integrity verification.

If a preserved file is later extracted from a Hunchly case and its SHA-256 digest still matches the recorded digest, that supports:

the file bytes have not changed relative to the recorded hash.

That is an integrity statement.

It is not automatic proof of original truth.

---

Hunchly itself warns that hashes are not magic

This is one of the strongest features of Hunchly's evidence documentation.

The product explicitly discusses potential evidence challenges.

Its guide explains that a matching hash alone cannot prove that content was not manipulated before the reference evidence package was created.

That is the correct forensic model.

A hash answers:

Is this file consistent with the recorded digest?

It does not answer:

Was every piece of content on the page authentic before capture?

This is why Hunchly combines integrity controls with:

• signatures;
• source validation;
• audit information;
• other corroboration.

---

GPG signing adds another integrity layer

Hunchly's current guide also describes automatic GPG signing.

When Hunchly is installed, it creates a key pair.

Captured MHTML evidence can be accompanied by:

PAGEID.mhtml
PAGEID.mhtml.sig

and the public key can be included with a case export.

The signature can help demonstrate whether the captured MHTML file has changed after signing.

Again, this adds integrity and auditability.

It does not remove the need to evaluate:

• source authenticity;
• capture context;
• investigator behavior;
• independent corroboration.

No evidence technology removes interpretation.

---

Deletion logging matters because cases change

Investigators sometimes delete irrelevant or sensitive captures.

That can create gaps.

Hunchly's evidence model includes deletion logging so those gaps can be explained.

This is important because a reviewable investigation is not only about:

what remains.

It is also about understanding relevant actions taken during evidence handling.

The more a case may later be scrutinized, the more valuable this kind of process transparency becomes.

---

Notes turn preserved pages into analytical evidence

A page can be captured perfectly and still be useless six months later if nobody remembers why it mattered.

Hunchly Notes are designed to solve that problem.

Current support documentation describes Notes as a way to:

• capture visible material;
• explain why it matters;
• use those notes later in reporting.

This ties:

artifact
+
analyst explanation

together.

That is an investigation function.

Archive systems can store the page.

Case systems try to preserve why the investigator cared.

---

Tags make the case navigable

Hunchly also supports tagging captured pages.

Tags can help organize themes such as:

ownership
timeline
key-source
contradiction
identity
needs-verification

This is useful because investigative evidence is rarely useful as a purely chronological list.

The investigator needs to group captures by:

• theme;
• entity;
• hypothesis;
• importance;
• review state.

Again, the organizing principle is the case.

---

Reporting is part of the Hunchly workflow

Hunchly's current product also emphasizes reporting.

The workflow can progress from:

capture
→ organize
→ review
→ report

This is a very different goal from:

URL
→ archive snapshot
→ preserve indefinitely

The first optimizes evidence communication.

The second optimizes preservation infrastructure.

Both are useful.

---

Local custody does not make Hunchly equivalent to ArchiveBox

Hunchly currently supports local storage workflows where investigation data lives on the investigator's computer.

That provides meaningful control over evidence.

But:

local custody

is not the same as:

operating a web archive platform.

Hunchly's data model remains tied to:

• investigative capture;
• evidence review;
• cases;
• reporting.

ArchiveBox is designed around a collection of archived URLs and snapshots.

The custody overlap should not hide the product-model difference.

---

ArchiveBox: the archive is the organizing unit

ArchiveBox describes itself as a self-hosted internet archiving solution.

The core workflow is:

feed URLs
↓
create snapshots
↓
store several representations
↓
index/manage collection
↓
repeat

The URL collection is central.

You can add URLs through several interfaces and input sources.

Current documentation describes interaction through:

• browser extension;
• CLI;
• self-hosted web interface;
• Python API;
• filesystem-related workflows.

The archive is not limited to pages encountered manually during one browsing session.

---

ArchiveBox is strongest when preservation becomes infrastructure

Suppose your research team maintains:

500 company pages
200 official notices
50 regulator pages
100 campaign sites

and wants to preserve them continuously.

The problem is no longer:

document what one investigator browsed today.

It is:

operate a collection that captures these targets consistently over time.

That is an ArchiveBox-shaped problem.

---

ArchiveBox supports repeated imports

Current ArchiveBox documentation describes the ability to feed it URLs:

• one at a time;
• through browser/bookmark workflows;
• through feeds;
• through scheduled or repeated imports.

This makes it useful for:

• recurring collections;
• monitored source sets;
• research archives;
• long-term preservation projects.

The operational question becomes:

which URLs belong in the archive?

rather than:

which pages did the investigator encounter during this case?

---

Multiple capture formats are a major ArchiveBox strength

ArchiveBox's current documentation describes several redundant snapshot formats for a page.

Depending on configuration, these can include:

• original HTML/resources;
• SingleFile;
• screenshot;
• PDF;
• WARC;
• DOM dump;
• extracted article text;
• response headers;
• media;
• other derived artifacts.

This matters because different formats preserve different properties.

Screenshot

Useful for visual appearance.

SingleFile

Useful for portable self-contained rendered HTML.

PDF

Useful for portable human review.

WARC

Useful for web-archive-oriented request/response preservation.

DOM dump

Useful for rendered structural analysis.

Original resources

Useful for local reconstruction and inspection.

Redundancy improves resilience.

---

ArchiveBox can use SingleFile — again showing that capture and archive management are separate

ArchiveBox can include SingleFile as one of its capture methods.

This demonstrates an important architectural distinction.

SingleFile answers:

How should I package this page into a portable HTML artifact?

ArchiveBox answers:

How should I manage this URL and its captures inside an archive?

A capture method can live inside an archive system.

Similarly, evidence captured during an investigation can later be preserved inside a wider archival system.

These layers should not be confused.

---

ArchiveBox can also store a Wayback reference

Current ArchiveBox documentation describes saving an Archive.org permalink as part of its archive outputs when configured.

This is another example of layered preservation.

An owned archive can coexist with:

• local snapshot;
• public third-party archive reference.

The strongest preservation workflow often combines:

owned copy + external historical reference

rather than forcing one system to do everything.

---

Self-hosting gives control and responsibility

ArchiveBox's strongest strategic advantage is also its largest operational cost.

You control:

• host;
• disks;
• archive database;
• access;
• capture configuration;
• backup strategy;
• retention;
• availability.

That means you must manage:

• installation;
• upgrades;
• browser dependencies;
• storage growth;
• backup;
• recovery;
• permissions;
• monitoring.

An archive is not durable simply because it is self-hosted.

If the disk fails and no backup exists, custody did not equal preservation.

---

ArchiveBox can preserve authenticated content — with major responsibility

Current ArchiveBox documentation includes support patterns for Chromium profiles/personas that can preserve pages visible to a logged-in browser session.

This is powerful.

It is also sensitive.

Authenticated archival can involve:

• account data;
• private pages;
• cookies/session state;
• personal information;
• contractual restrictions.

Use it only where you are authorized and where retention is appropriate.

The fact that a tool can technically capture authenticated content does not make every capture lawful or proportionate.

---

Hunchly and ArchiveBox have different time models

This is another useful distinction.

Hunchly time model

The investigation unfolds through browsing.

Captures correspond to:

what the investigator encountered at a particular moment in the case.

ArchiveBox time model

The archive evolves through URL ingestion and repeated collection.

Captures correspond to:

preserved states of URLs within an archive collection.

One is case chronology.

The other is archive chronology.

They can overlap.

They are not identical.

---

Hunchly is stronger when intent and interpretation matter immediately

Imagine you capture a page because:

the legal footer contradicts the company registry.

The important package includes:

page
URL
timestamp
hash/signature
note explaining contradiction
related case material

Hunchly is built around keeping those pieces close together.

The analytical context is part of the case.

---

ArchiveBox is stronger when target continuity matters

Now imagine you need to preserve:

company.example/terms
company.example/privacy
company.example/team

every day for six months.

The important system includes:

URL inventory
capture schedule
multiple snapshot formats
storage
indexing
backup
change review

That is archive infrastructure.

The analyst note may come later when a meaningful change occurs.

---

Worked example 1 — one investigative case

Question:

Did this company change the legal entity named on its website during the acquisition period?

The investigator is browsing:

• current Terms;
• archived pages;
• registry records;
• news articles.

Hunchly-first

This is a natural fit.

Capture relevant pages as research progresses.

Tag:

identity
timeline
ownership

Add notes explaining:

• what each capture shows;
• why it matters.

Export/report selected findings later.

ArchiveBox

Useful if the company is also part of an ongoing monitoring collection.

But deploying an archive platform only for one small case may be unnecessary.

---

Worked example 2 — recurring target collection

Question:

Preserve 1,000 public policy pages every week.

Hunchly is not the natural primary architecture.

The problem is collection infrastructure.

ArchiveBox-first

Maintain:

• URL list;
• scheduled imports;
• snapshots;
• storage;
• backup.

When a meaningful change becomes part of a human investigation, selected material can be examined and packaged through a case workflow.

---

Worked example 3 — sensitive investigation

An investigator visits public pages containing sensitive personal data.

Hunchly

Local evidence capture can keep the case data under investigator control.

Notes and reports can be managed deliberately.

ArchiveBox

A private self-hosted archive can also preserve the material.

But because ArchiveBox may preserve multiple formats and recurring copies, ask:

• Is broad retention necessary?
• Who can access the archive?
• How long should the data remain?
• Are backups protected?

Archive depth can increase privacy risk.

---

Worked example 4 — disappearing page during research

You encounter a page likely to change.

Hunchly

If the case is already running in Hunchly, the page can be captured automatically as part of the investigative trail.

This is low-friction.

ArchiveBox

You can add the URL to the archive for controlled preservation and possibly future repeated snapshots.

Best combined pattern

Hunchly → immediate case evidence
ArchiveBox → ongoing target preservation
Wayback → independent historical/public context where appropriate

Each tool has a distinct job.

---

Worked example 5 — court or formal review risk

The research may later be reviewed by:

• lawyer;
• regulator;
• court;
• client;
• internal investigations team.

Hunchly's evidence-oriented controls become especially relevant:

• MHTML captures;
• SHA-256;
• signatures;
• deletion logs;
• case exports;
• notes/reporting.

ArchiveBox can preserve strong supporting artifacts.

But it should not automatically be described as:

formal evidence management

unless your organization has built the required procedures around it.

A technical archive is not a legal chain-of-custody policy by itself.

---

Hashing and signing solve integrity questions, not truth

Suppose Hunchly's hash and GPG signature verify correctly.

You can say:

This evidence file is consistent with the captured/signed artifact represented by the case data.

You still cannot automatically say:

The original website statement was factually true.

Likewise, an ArchiveBox WARC or screenshot can preserve what was retrieved.

It does not validate the truth of the content.

Preservation and verification remain distinct.

---

Archive redundancy is not independent corroboration

ArchiveBox may preserve the same URL as:

screenshot
PDF
SingleFile
WARC
DOM

That is excellent preservation redundancy.

It is not five independent sources.

All representations derive from the same archival event or source state.

Independent corroboration could involve:

• official registry;
• second website;
• Wayback historical capture;
• separate observer;
• authoritative dataset.

Do not count formats as sources.

---

Case captures are not automatically independent either

Hunchly may preserve:

• MHTML;
• photo;
• note;
• screenshot/report output.

These may all relate to the same underlying page.

A strong case keeps the distinction between:

multiple artifacts about one observation

and:

multiple independent observations.

---

What Hunchly does not replace

Hunchly does not replace:

• a broad long-term web archive;
• organizational backup strategy;
• historical archive services;
• primary-source verification;
• legal evidence procedures where specifically required.

It is strongest as an investigative capture and evidence-packaging environment.

---

What ArchiveBox does not replace

ArchiveBox does not replace:

• investigator notes;
• analytical reasoning;
• case chronology;
• formal evidence reports;
• entity resolution;
• source verification;
• legal chain-of-custody policy.

It is strongest as owned web-archive infrastructure.

---

A decision framework

Choose Hunchly when the primary object is:

the investigation.

Ask:

• What did I see?
• When?
• Why did I save it?
• How is it related to the case?
• Can another reviewer understand my trail?

Choose ArchiveBox when the primary object is:

the collection.

Ask:

• Which URLs should be preserved?
• How often?
• In which formats?
• Where are snapshots stored?
• How are they backed up?
• How will the archive scale?

This is the cleanest difference.

---

A practical scoring matrix

These are workflow-fit scores.

Not universal product ratings.

---

Use SingleFile and Wayback to understand the edges

The current OSINT.dev graph also connects this comparison to:

• SingleFile;
• Wayback Machine.

That is useful because they clarify two additional preservation layers.

SingleFile

A capture mechanism.

Question:

Can I save this page into one portable local HTML file?

ArchiveBox can itself use SingleFile among its capture methods.

Hunchly instead uses MHTML as its core web-page evidence representation.

Wayback Machine

A third-party historical/public archive.

Question:

Does an independently operated public archive preserve a historical state of this page?

Wayback can corroborate historical context.

It does not replace investigator-controlled evidence or archive ownership.

---

A mature layered preservation model

For high-value research, think in layers.

Layer 1 — active case capture

Example:

Hunchly

Purpose:

• browsing trail;
• case evidence;
• notes;
• hashes/signatures;
• reporting.

Layer 2 — owned archive infrastructure

Example:

ArchiveBox

Purpose:

• target inventory;
• recurring preservation;
• multiple formats;
• self-hosted custody.

Layer 3 — portable point capture

Example:

SingleFile

Purpose:

• lightweight single-page preservation.

Layer 4 — external historical reference

Example:

Wayback Machine

Purpose:

• third-party historical states.

A mature evidence program may use more than one layer.

---

A combined Hunchly + ArchiveBox workflow

When both genuinely help:

1. Investigate in Hunchly

Capture the browsing trail.

Use:

• tags;
• notes;
• cases;
• evidence controls.

2. Identify durable targets

Not every page belongs in long-term archival infrastructure.

Promote only URLs that matter repeatedly.

3. Add selected URLs to ArchiveBox

Preserve:

• current snapshots;
• multiple representations;
• repeated states where required.

4. Back up the archive

ArchiveBox control is only valuable if storage is resilient.

5. Keep the evidence relationship explicit

Example:

Hunchly EV-0042
source_url: https://example.com/terms

ArchiveBox snapshot:
same URL
archived_at: ...

6. Use historical third-party sources when useful

Wayback can add independent temporal context.

7. Report from the case, not from the raw archive alone

The archive stores evidence.

The case explains its significance.

---

Operational questions before choosing ArchiveBox

Ask:

• Who maintains it?
• Where does it run?
• How much storage will captures consume?
• Which extractors are enabled?
• How often are URLs revisited?
• Are authenticated captures allowed?
• How are credentials protected?
• How is backup performed?
• Who has access?
• What is the retention policy?

If those questions have no owner, archive self-hosting may be premature.

---

Operational questions before choosing Hunchly

Ask:

• Is the investigator working primarily in a supported browser workflow?
• Are case files stored and backed up appropriately?
• Are exports controlled?
• Are notes/reporting conventions defined?
• How are sensitive captures handled?
• Who can access the case data?
• What evidence standard does the downstream reviewer expect?

Investigator-first software still requires organizational procedure.

---

Privacy and minimization apply to both

Preservation can create a second copy of personal information.

Repeated preservation can create many copies.

Ask:

• Is this page necessary?
• Do we need the whole page?
• Do we need recurring captures?
• How long should the evidence be retained?
• Is access restricted?
• Is public archiving appropriate?

A stronger archive is not automatically a more proportionate archive.

---

Common mistakes

Mistake 1 — Calling Hunchly and ArchiveBox direct substitutes

They center different workflows.

Mistake 2 — Treating Hunchly as only screenshots

Its evidence model includes MHTML, hashes, signatures and audit controls.

Mistake 3 — Treating ArchiveBox as merely "save webpage"

It is an archive-management system with many capture methods.

Mistake 4 — Assuming self-hosting automatically means durable custody

Backups and maintenance still matter.

Mistake 5 — Assuming signed/hashed evidence proves page truth

Integrity and authenticity are separate.

Mistake 6 — Treating multiple snapshot formats as independent sources

They can all derive from one capture.

Mistake 7 — Sending every investigated page into long-term archival storage

Promote selectively.

Mistake 8 — Using a case tool as the only backup

Case storage still needs resilience.

Mistake 9 — Using an archive as a substitute for analyst notes

Preserved pages do not explain themselves.

Mistake 10 — Capturing authenticated/private material just because the platform supports it

Authorization and proportionality still apply.

Mistake 11 — Ignoring retention

Preservation creates ongoing responsibility.

Mistake 12 — Asking which product is "more forensic"

Define the evidence requirement first.

---

Which tool should you open first?

Open Hunchly first when the unresolved problem is:

How do I preserve and explain the investigative trail as I research?

Open ArchiveBox first when the unresolved problem is:

How do I operate a controlled archive of these URLs over time?

Use both when the organization needs:

case evidence + archive continuity

That is the cleanest division of responsibility.

---

Related OSINT.dev tools and guides

Hunchly

Best for:

• investigator-centered page capture;
• evidence organization;
• notes/tags;
• SHA-256/GPG-backed evidence handling;
• audit trail;
• reporting.

ArchiveBox

Best for:

• self-hosted URL collections;
• recurring archival;
• multi-format snapshots;
• archive ownership;
• long-term preservation infrastructure.

SingleFile

Best for:

• low-friction portable HTML capture.

It is a capture method, not a full investigation or archive-management environment.

Wayback Machine

Best for:

• external public historical context.

It can provide independent archival history that neither your Hunchly case nor newly created ArchiveBox instance can retroactively generate.

Building a Lightweight Evidence Capture Workflow

Use the broader OSINT.dev guide when the question is:

What metadata, timestamps, hashes, provenance and storage discipline should surround any evidence capture?

This comparison answers:

Which operating model fits the preservation problem?

The evidence guide answers:

How should the evidence lifecycle itself work?

---

The core principle

Hunchly and ArchiveBox preserve different things at the organizational level.

Hunchly primarily preserves:

the investigator's evidence trail.

ArchiveBox primarily preserves:

the archive collection.

That leads to two different questions:

Hunchly — What did the investigator observe, preserve and conclude during the case?

ArchiveBox — Which web resources does the organization preserve, in which formats, under which archive policy, over time?

A mature OSINT program may need both answers.

Do not choose based on which product has the longer feature list.

Choose based on what must still be understandable in six months:

• the case,
• the archive,
• or both.

---

References

Official/current product documentation used in this comparison:

• Hunchly — Official product overview
  https://hunch.ly/

• Hunchly — Evidence Guide
  https://support.hunch.ly/category/50-hunchly-evidence-guide

• Hunchly — Evidence Introduction
  https://support.hunch.ly/article/55-1-hunchly-evidence-introduction

• Hunchly — The MHTML File Format
  https://support.hunch.ly/article/51-1-the-mhtml-file-format

• Hunchly — Content, Photo and Attachment Hashing
  https://support.hunch.ly/article/52-2-content-photo-and-attachment-hashing

• Hunchly — GPG Signing and Validation
  https://support.hunch.ly/article/53-3-gpg-signing

• Hunchly — Using Notes
  https://support.hunch.ly/article/23-5-using-notes-in-hunchly

• Hunchly — Using Tags
  https://support.hunch.ly/article/19-3-how-to-use-hunchly-tags

• ArchiveBox — Current Key Features
  https://docs.archivebox.io/latest/README.html

• ArchiveBox — Usage
  https://docs.archivebox.io/latest/Usage.html

• ArchiveBox — Installation
  https://docs.archivebox.io/latest/Install.html

• ArchiveBox — Chromium / authenticated capture setup
  https://docs.archivebox.io/latest/Chromium-Install.html