article · featured

Wayback Machine vs SingleFile vs ArchiveBox: Which Preservation Tool Fits Which Job?

Choose the right web-preservation tool by job: Wayback Machine for public history, SingleFile for immediate portable local capture, and ArchiveBox for a self-hosted archive you control.

published
Apr 21, 2026
updated
Aug 19, 2026
slug
wayback-machine-vs-singlefile-vs-archivebox
status
Published

Wayback Machine vs SingleFile vs ArchiveBox: Which Preservation Tool Fits Which Job?

"Save the page" sounds like one task.

In practice, it can mean at least three different things:

  1. recover a public state from the past
  2. capture what you can see right now
  3. maintain an archive you control over time

Wayback Machine, SingleFile and ArchiveBox are often placed in the same preservation category because all three can help keep web content available after the live page changes.

But they solve different operational problems.

The wrong comparison asks:

Which one is the best web archiving tool?

The useful comparison asks:

What preservation problem am I trying to solve, who needs to control the copy, and how repeatable does the workflow need to be?

A strong OSINT workflow may use all three.

The important part is knowing why.


The short answer

If your main question is:

What did this public page look like before?

Start with Wayback Machine.

If your main question is:

I need a portable local copy of this page now.

Start with SingleFile.

If your main question is:

I need an archive system I control for many URLs and repeated collection.

Start with ArchiveBox.

That is the basic distinction.

The rest of this guide explains the tradeoffs behind it.


Comparison at a glance

NeedWayback MachineSingleFileArchiveBox
recover historical public pagesstrongestnoonly if you captured them earlier
capture a live page immediatelyyes, via Save Page Nowstrongest low-friction optionyes
local artifact you directly controlnoyesyes
self-hosted archivenonoyes
single portable HTML filenot the core modelyescan use SingleFile among capture methods
multi-format archivalarchive-managedmainly single HTMLyes
recurring archive collectionnot investigator-controlled in the same waymanual/CLI possiblestrongest
public third-party referencestrongestnono unless you publish it yourself
infrastructure/maintenance burdennone for uservery lowhighest
case-scale organizationlimited for your own case workflowmanualstronger archive management
useful offline copylimited by archive/replay contextyesyes
best rolehistorical/public referenceimmediate captureowned archive system

This table is a starting point.

The correct choice still depends on:

  • sensitivity;
  • scale;
  • evidence requirements;
  • privacy;
  • storage;
  • maintenance;
  • whether a third-party public archive is appropriate.

Wayback Machine: public historical memory

The Wayback Machine is operated by the Internet Archive.

Its core value for an investigator is historical access.

You can ask:

  • Was this URL archived before?
  • What wording appeared on an older version?
  • Did branding change?
  • Did the page exist before a migration?
  • What did a legal footer say at another point in time?
  • Is there a public archive URL I can cite?

That makes Wayback fundamentally different from a local capture tool.

It gives you access to captures that may predate your investigation.

SingleFile cannot do that.

ArchiveBox cannot do that unless someone using your ArchiveBox instance already preserved the page.


Save Page Now changes the role slightly

The Wayback Machine also provides Save Page Now.

Internet Archive's current help documentation says Save Page Now can save a specific page one time into the Wayback Machine.

That means Wayback has two useful investigative roles:

Historical lookup

What has already been archived?

Public preservation request

Can I ask the archive to preserve this specific public page now?

Those roles are valuable.

They still do not make Wayback equivalent to a private evidence repository.

The captured material is being placed into a third-party public archival environment.

That has consequences.


When Wayback is the strongest first choice

Use Wayback first when the research depends on time before your observation.

Examples:

Corporate identity change

Current Terms:

Operated by NewCo Ltd

Historical capture:

Operated by OldCo Ltd

Wayback can help narrow the public transition period.

Website migration

Current domain redirects elsewhere.

Historical captures show the previous site structure and branding.

Deleted public statement

A page has disappeared, but an older archive contains a representation of it.

Historical contact information

An old address, phone number or organization name appeared on a public page and is relevant to a timeline.

These are history questions.

SingleFile and ArchiveBox can preserve future states.

They cannot retroactively create the missing past.


Wayback's strongest evidentiary feature is independence

A Wayback capture has a useful property:

it is not stored only inside the investigator's own local evidence folder.

That can give the analyst an independent archival reference.

This does not mean:

Internet Archive certifies every historical fact on the page.

The archive preserves a representation associated with its archival system.

The content still needs interpretation.

But third-party preservation can be valuable when corroborating that publicly available material existed in some archived form at an earlier time.


Wayback's main limitation: you do not control its historical coverage

The most important practical limitation is obvious:

if the page you need was never captured in the relevant period, Wayback cannot reconstruct it for you after the fact.

Save Page Now helps with the present.

It does not solve missing historical coverage.

Likewise, one archived timestamp does not prove that the page remained unchanged for the entire period between two captures.

A good historical conclusion sounds like:

Capture A shows wording X on date A, and capture B shows wording Y by date B.

Not:

The page changed exactly on the first day after capture A.

Archive evidence often defines a window, not an exact event time.


Wayback is not your private case file

Do not use a public archive as the default destination for material that should not be publicly archived.

Before using Save Page Now, ask:

  • Is the source already legitimately public?
  • Is public archival appropriate?
  • Does the URL contain sensitive tokens?
  • Does the page expose unnecessary personal information?
  • Would preservation itself increase harm?

Evidence preservation and public publication are not the same decision.

For sensitive investigation material, a local or controlled archive may be more appropriate.


SingleFile: immediate local capture

SingleFile has a much narrower idea.

Its official project describes it as a tool for saving a complete web page into a single HTML file.

It is available as a browser extension and also has command-line tooling.

That simplicity is its strongest feature.

Instead of producing:

page.html
page_files/
  style.css
  image1.jpg
  script.js

you get one portable HTML artifact.

For active research, that is extremely convenient.


SingleFile's best use case is "preserve this now"

Imagine you are browsing a page that matters.

You do not yet know whether it will become a major finding.

But it may change.

SingleFile gives you a low-friction action:

save a portable local representation before continuing the analysis.

That makes it especially useful for:

  • solo investigators;
  • ad hoc research;
  • field collection;
  • volatile pages;
  • pages you want to review offline;
  • evidence triage.

The workflow can be:

observe
→ save SingleFile
→ screenshot
→ record URL/time
→ continue research

If the artifact later becomes important, you can promote it into a more structured evidence package.


SingleFile minimizes archive overhead

SingleFile does not require you to operate:

  • a server;
  • a database;
  • an archive index;
  • a background service.

This is important.

Infrastructure has a cost.

A sophisticated archive you do not maintain is less useful than a simple capture workflow you actually use.

For small investigations, SingleFile can therefore be the best answer even if ArchiveBox is technically more powerful.


A single HTML file is easy to hash and store

Because the result is one file, you can easily:

  • give it a stable evidence ID;
  • calculate SHA-256;
  • move it into a case folder;
  • attach metadata;
  • back it up;
  • reopen it later.

Example:

EV-0042_page.html
EV-0042_metadata.json
EV-0042_screenshot.png

This fits naturally into a lightweight evidence-capture workflow.

But remember:

a hash proves integrity relative to the recorded digest, not the original truth of the web page.

SingleFile gives you a capture artifact.

Provenance still comes from your evidence record.


SingleFile is not automatically a complete browser-forensics record

"Complete web page" describes the project's capture objective.

It should not be interpreted as:

every possible network interaction and dynamic state of the browsing session has been forensically preserved.

Modern web pages can depend on:

  • JavaScript execution;
  • API responses;
  • authentication state;
  • embedded content;
  • browser storage;
  • service workers;
  • live network requests.

A self-contained HTML page can be excellent evidence for the rendered page state you preserved.

It is not necessarily a complete network trace.

Match the artifact to the research question.


SingleFile requires organization at scale

The simplicity that makes SingleFile excellent at low volume can become a management problem at high volume.

If you save 10 pages:

easy

If you save 100,000 pages:

you need an archive system

At scale, you need:

  • indexing;
  • metadata;
  • deduplication;
  • search;
  • retention;
  • storage planning;
  • backups;
  • repeat capture;
  • automation.

SingleFile itself is a capture mechanism.

It does not automatically become your archive-management architecture.


ArchiveBox: archive ownership

ArchiveBox is a self-hosted web-archiving platform.

Its documentation describes an architecture where you feed it URLs and it stores snapshots locally in several common formats.

Current ArchiveBox documentation lists output formats including combinations of:

  • HTML;
  • PNG screenshots;
  • PDF;
  • TXT;
  • JSON;
  • WARC;
  • SQLite-related archive data;

and it supports capture methods that can include SingleFile.

That is a very different operational model from clicking Save Page in a browser.

ArchiveBox is infrastructure.


ArchiveBox's best question is "do I need an archive I operate?"

Use ArchiveBox when preservation becomes a recurring system rather than an occasional action.

Examples:

  • monitor a list of important public pages;
  • maintain a research archive over months;
  • preserve many URLs in multiple formats;
  • keep the archive inside infrastructure you control;
  • integrate capture with scripts or other services;
  • search and revisit previously archived targets.

The value is not simply:

ArchiveBox saves pages better.

The value is:

ArchiveBox turns preservation into an owned process.


Archive ownership creates responsibility

Self-hosting is often described only as an advantage.

It also means you become responsible for:

  • installation;
  • upgrades;
  • storage growth;
  • access controls;
  • backups;
  • availability;
  • privacy;
  • security;
  • retention;
  • recovery.

If you deploy ArchiveBox and never back it up, you have not created durable preservation.

You have created another single point of failure.

Use self-hosting when you actually need the control.


Multi-format capture is useful because formats fail differently

ArchiveBox can preserve several representations of the same URL.

That can be useful because:

  • screenshot preserves appearance;
  • PDF offers a portable document representation;
  • HTML preserves page structure;
  • SingleFile offers self-contained HTML;
  • WARC supports web-archive-oriented preservation;
  • extracted text can support search.

These outputs are not duplicates in the strict analytical sense.

They preserve different properties.

A screenshot may show a visual claim that an HTML parser misses.

A WARC may preserve HTTP-oriented archival material that a screenshot cannot.

A PDF may be convenient for review but less useful for later source inspection.

Multi-format preservation can improve resilience.


ArchiveBox can use SingleFile — so they are not true substitutes

This is an important point in the comparison.

ArchiveBox can use SingleFile as one of its page-capture methods.

Therefore:

ArchiveBox vs SingleFile

is not always a direct either/or choice.

You can use:

SingleFile inside an ArchiveBox workflow.

The real difference is:

SingleFile alone

A capture tool.

ArchiveBox

An archive-management system that can orchestrate multiple capture formats and methods.

That distinction makes tool choice much clearer.


Wayback and ArchiveBox are also complementary

They solve different control problems.

Wayback gives you:

  • public historical coverage;
  • third-party archival context.

ArchiveBox gives you:

  • your own archive;
  • your own collection policy;
  • your own retention;
  • your own storage.

A high-value target can reasonably exist in both.

Example:

Wayback → historical context before investigation
ArchiveBox → investigator-controlled ongoing archive
SingleFile → fast local artifact for the specific evidence package

The tools form layers.

They do not need one winner.


Decision dimension 1 — Past or present?

Ask:

Do I need something from before I began investigating?

If yes:

Wayback first.

Neither SingleFile nor your newly deployed ArchiveBox can create historical states that were never previously preserved.

If no, continue to the next question.


Decision dimension 2 — One page or many?

If you need one or a few captures:

SingleFile is often the lowest-friction choice.

If you need a repeatable collection across many URLs:

ArchiveBox becomes more attractive.

Wayback remains useful as an independent archival layer.


Decision dimension 3 — Public archive or private control?

If a public third-party archive is appropriate:

Wayback can provide an external archival reference.

If the material should remain inside your own research environment:

SingleFile or ArchiveBox are better fits.

For sensitive material, think before submitting anything to a public archival service.


Decision dimension 4 — Capture or archive management?

If the problem is:

make a local copy now

choose SingleFile.

If the problem is:

manage preservation as an ongoing system

choose ArchiveBox.

This is one of the cleanest distinctions in the whole comparison.


Decision dimension 5 — Maintenance tolerance

Ask:

Do I want to operate infrastructure?

If the answer is no:

ArchiveBox may be unnecessary.

SingleFile has very low operational overhead.

Wayback requires no self-hosted infrastructure.

A tool should match your operational capacity.


Decision dimension 6 — Evidence independence

If you want an archived state maintained independently of your own local case files:

Wayback can add value.

If you need exact control over:

  • file;
  • hash;
  • local storage;
  • private notes;
  • access;

use your own capture.

Often the strongest important-page workflow uses both.


Decision dimension 7 — Repeated capture

If you want to revisit the same URLs over time, ArchiveBox is the strongest of these three as an owned archive platform.

You can schedule or integrate archival collection around it.

SingleFile can be automated through tooling, but the archive-management problem remains yours.

Wayback's collection exists outside your own workflow control.


A practical scoring matrix

RequirementWaybackSingleFileArchiveBox
historical lookup5/50/50/5 unless already captured
immediate local capture2/55/54/5
public third-party reference5/50/50/5
private local control0/55/55/5
low setup5/55/52/5
archive management2/51/55/5
multi-format capturearchive-specific1/55/5
repeated collectionexternal archive model2/55/5
investigator-controlled retention0/54/55/5
good first tool for beginners5/55/52/5

These scores describe workflow fit.

They are not universal quality grades.


Worked example 1 — deleted company page

Question:

Did this company previously claim a partnership that is no longer on its website?

Start with Wayback

Search the historical URL.

An archived capture contains the partnership claim.

Now you have historical evidence.

Use SingleFile?

You cannot use SingleFile to capture the deleted historical live page.

But you can use it to preserve:

  • the current replacement page;
  • related current company pages;
  • other relevant live context.

Use ArchiveBox?

If this company is part of a long-running monitoring project, add the current relevant URLs to your archive.

Best workflow

Wayback → recover historical claim
SingleFile → capture current live comparison
ArchiveBox → preserve future changes

No single tool does all three jobs.


Worked example 2 — volatile breaking-news page

Question:

This live page is changing quickly. I need to preserve what is visible now.

Start with SingleFile

Capture the current page immediately.

Record:

  • URL;
  • UTC time;
  • screenshot;
  • hash;
  • note.

Consider Wayback Save Page Now

If public archival is appropriate, request an external public capture too.

ArchiveBox?

Useful if the target belongs to a recurring monitoring collection.

For one emergency capture, deploying a new ArchiveBox instance would probably be excessive.

Best workflow

SingleFile first
→ Wayback if appropriate
→ ArchiveBox only if ongoing monitoring justifies it

Worked example 3 — long-term monitoring

Question:

We need to preserve 500 public pages every week for one year.

SingleFile alone creates a management problem.

Manual Save Page Now requests do not give you the archive ownership and scheduling model you need.

ArchiveBox is much closer to the requirement.

A sensible architecture might be:

URL inventory
→ scheduled ArchiveBox capture
→ multiple formats
→ storage monitoring
→ backups
→ analyst review

Wayback remains useful for historical states before your collection started.

SingleFile may still be one of the capture formats inside ArchiveBox.


Worked example 4 — sensitive research page

Question:

A public page contains sensitive personal information relevant to an investigation. We need evidence but should minimize further exposure.

Do not automatically submit it to a public archive.

A controlled local capture may be more appropriate.

You might use:

SingleFile
→ encrypted case storage
→ hash
→ access restriction

or your controlled ArchiveBox environment if it is configured appropriately for sensitive material.

Preservation decisions can create their own privacy consequences.


What none of these tools proves

This is the most important evidence warning.

None of the three automatically proves:

  • that the page content was true;
  • that the claimed author was genuine;
  • that every resource loaded correctly;
  • that the page was unchanged before capture;
  • that a screenshot represents every user experience;
  • that an archived timestamp is the exact publication time.

The tools preserve observations.

The analyst establishes meaning.


Capture time is not publication time

Suppose Wayback has a capture at:

2026-07-10

That proves the archive associated a captured representation with that time.

It does not necessarily prove the page was first published on 10 July.

Likewise, if you save a SingleFile copy on 18 August, that is:

your observation/capture time

not:

page publication date.

Always keep those timestamps distinct.


Public archive and local hash solve different trust questions

A third-party archive can help answer:

Is there an independently maintained archived representation?

A local SHA-256 hash can help answer:

Has my stored file changed relative to the digest I recorded?

Those are different trust functions.

Using both can be valuable.

One does not replace the other.


Tool choice should follow the evidence lifecycle

Think about the life of a web observation.

Discover

Historical evidence may already exist.

Use Wayback.

Capture

You encounter something important now.

Use SingleFile or another local capture method.

Promote

The evidence becomes important.

Add structured metadata, hash, screenshot and notes.

Archive

The target becomes part of ongoing collection.

Use ArchiveBox or another archive-management system.

Corroborate

Use third-party historical archives and independent sources.

This lifecycle explains why mature workflows often combine tools.


Common mistakes

Mistake 1 — Asking which tool is the overall winner

They solve different preservation jobs.

Mistake 2 — Waiting until the page disappears

If the live page matters, capture it now.

Mistake 3 — Treating Wayback as guaranteed history

Historical coverage can be incomplete.

Mistake 4 — Treating SingleFile as an archive-management system

It is primarily a capture mechanism.

Mistake 5 — Deploying ArchiveBox for a one-page task

Operational complexity should serve a real need.

Mistake 6 — Forgetting backups for self-hosted archives

Self-hosting without backup is not durable preservation.

Mistake 7 — Publicly archiving sensitive URLs automatically

Public preservation is itself a disclosure decision.

Mistake 8 — Treating one HTML file as complete forensic capture

Match the artifact to the question.

Mistake 9 — Confusing capture time with publication time

Every timestamp has a specific meaning.

Mistake 10 — Believing a hash proves authenticity

A hash supports integrity of the stored bytes after the reference digest exists.


Recommended beginner setup

For a researcher starting today:

Use Wayback Machine for

  • historical lookup;
  • timeline reconstruction;
  • public archive references.

Install SingleFile for

  • immediate local capture;
  • volatile pages;
  • portable evidence files.

That combination covers a surprising amount of real work.

Do not deploy a self-hosted archive solely because it sounds more professional.


Recommended recurring-research setup

When web preservation becomes part of your routine:

Wayback Machine
+ SingleFile
+ ArchiveBox

can become a strong layered system.

Use:

  • Wayback for outside historical/public context;
  • SingleFile for frictionless investigator capture;
  • ArchiveBox for archive ownership and repeated preservation.

The overlap is useful because each layer can compensate for a different weakness.


Related OSINT.dev tools

Wayback Machine

Best for:

  • public historical states;
  • timeline comparison;
  • third-party archival reference.

SingleFile

Best for:

  • immediate local page capture;
  • portable single-file HTML;
  • low-friction evidence collection.

ArchiveBox

Best for:

  • self-hosted archive ownership;
  • repeated collections;
  • multiple capture formats;
  • archive management.

Building a Lightweight Evidence Capture Workflow

Use the broader OSINT.dev evidence guide when the question is not only which tool to choose, but also:

  • timestamps;
  • evidence IDs;
  • hashes;
  • provenance;
  • original vs derived artifacts;
  • storage;
  • backup;
  • privacy.

This comparison is the tool-selection layer.

The evidence workflow is the process layer.


The core principle

Choose by preservation problem.

Use this decision sequence:

Do I need the past? → Wayback

Do I need this live page locally right now? → SingleFile

Do I need a repeatable archive I operate? → ArchiveBox

Then ask whether the finding is important enough to combine approaches.

For high-value public evidence, a strong pattern can be:

historical archive + local capture + owned archive + provenance

Preservation is strongest when each tool has a clearly defined job.

The right question is not:

Which tool saves webpages best?

It is:

Which preservation function is missing from my current evidence workflow?


References

Official documentation used in this comparison:

tagsEthicalDocumentsEvidenceWorkflow
cite this article

OSINT.dev · Published Apr 21, 2026 · Updated Aug 19, 2026. Canonical URL: https://osint.dev/articles/wayback-machine-vs-singlefile-vs-archivebox

03explore next

Related articles.

Editorial pieces that share a tool context or type with this one.