How to preserve a web page as evidence

Sooner or later a dispute turns on what a website said. A supplier's refund terms, a competitor's product claim, a post that defamed your client, an offer that was withdrawn the day after you accepted it. By the time anyone asks for proof, the page has usually changed.

The usual reflex is a screenshot. Courts admit screenshots all the time, so this is not an argument that they are worthless. The trouble starts when the other side says that is not what our site said. At that point you need more than a picture. You need to show where the page came from, when it was saved, and that nobody has changed it since.

This article covers what a web capture has to record to answer those questions, and a practical checklist for making one.

Why a screenshot is weak evidence

A screenshot records pixels. Everything that makes a page trustworthy as evidence sits outside those pixels:

• The address. A screenshot shows whatever URL was in the address bar, if the browser chrome was included at all. It cannot show that the page was actually served from that address, or that a redirect didn't land somewhere else.
• The time. The date comes from the computer that took it, which its owner controls. The file's own timestamps change when it is copied.
• Integrity. An image can be edited without trace, and everyone involved knows it. Opposing counsel doesn't have to prove it was edited, only that it could have been.
• The rest of the page. A screenshot is one viewport, or a stitched strip that can drop sections. Text you can't select, links you can't follow and fine print below the fold are the usual casualties.

"Print to PDF" has similar gaps. It keeps the text but reflows the layout into print styles, often hides elements, and carries no independent record of where or when it was made.

What authentication actually asks for

The details vary by jurisdiction, but the question is always the same: is this item what you say it is?

In US federal courts, Federal Rule of Evidence 901(a) asks for "evidence sufficient to support a finding that the item is what the proponent claims it is". For web pages, that has traditionally meant a witness who testifies to how and when they captured it. Since 2017, Rule 902(14) also lets data copied from an electronic file be self-authenticating when it is identified by a "process of digital identification", which in practice means a hash, and certified by a qualified person.

Most European civil courts weigh evidence freely, so the question is how much weight a capture gets, not whether it gets in. Here the EU's eIDAS Regulation is relevant. Article 41 says an electronic timestamp can't be denied legal effect or admissibility as evidence just because it is electronic, or because it isn't a qualified timestamp. Qualified timestamps get a legal presumption of accuracy; others are weighed like any other evidence.

In both systems, a capture is stronger the less it depends on you personally vouching for it.

What a capture should record

A capture that stands up to a challenge answers five questions without anyone having to take your word for it.

1. What exactly was on the page?

Save the whole page as it rendered in a real browser: the text, the layout, the images and the fine print, not a crop of one screen. The saved copy should open later without depending on the original site, because the original site is the thing that changes. A self-contained HTML file does this. A folder of assets saved by "Save page as" often doesn't: it half-loads a year later, or quietly fetches today's images from the live site.

Keep a plain-text version too. Text is what you quote in a brief, search across hundreds of captures, and compare between two dates.

2. Where did it come from?

Record the address you asked for and the address the browser ended up on. They differ whenever there is a redirect, and a redirect is exactly the kind of detail that gets argued about. Details of how the site was hosted at the time, such as the addresses it answered on and the TLS certificate it presented, help to answer "are you sure that was our server?"

3. When was it captured, according to someone other than you?

This is where most captures are weakest. The capture time on your own system is your word. An RFC 3161 trusted timestamp is someone else's: an independent timestamping authority signs a statement that a file with a given fingerprint existed at a given moment. It never sees the file itself, only its fingerprint.

Anyone can check that token later with standard tools, without trusting you or the service that captured the page.

4. Has it changed since?

Compute a cryptographic fingerprint (a SHA-256 hash) of the saved file at the time of capture, and store the file where it can't be edited. If a single byte changes, the hash changes and the timestamp no longer verifies. That turns "we promise nobody touched it" into something the other side can check for themselves.

5. Who captured it, how and why?

Keep a record of who made the capture, with what tool, and a note of why. Months later, "why did we save this?" is a surprisingly hard question. An activity log that shows who captured, shared or deleted what, and when, does most of the work of a chain-of-custody statement.

A checklist for preserving a web page

1. Capture early. Do it before you send a letter, file a complaint or post publicly about the dispute. Pages change fastest once their owner knows someone is watching.
2. Capture everything relevant, not just the headline page. Terms and conditions, the pricing page, the FAQ that contradicts them, linked PDFs, and the page that links to all of them.
3. Use a real browser capture, not a screenshot. Keep the full page as a self-contained file, plus a text version.
4. Get an independent timestamp at the time of capture. A timestamp requested months later only proves the file existed months later.
5. Record the hash and keep the original untouched. Work from copies. Never "tidy up" the saved file.
6. Capture again on a schedule if the page is likely to change. A series of dated captures shows what changed and when, which a single capture never can.
7. Write a short note with each capture: the matter it belongs to, and what to look for.
8. Keep the verification instructions with the file. Whoever checks it in three years should not need to call you.

If the page has already changed, check whether a public archive such as the Wayback Machine holds an earlier copy. We cover what that can and can't prove in Wayback Machine captures as evidence.

How Archivepanel handles it

We built Archivepanel for exactly this job, so here is briefly what a capture records:

• A real Chromium saves the page as one self-contained HTML file, with every stylesheet, image and font embedded and every script removed, so it opens offline and can't change when opened.
• The record keeps the address requested and the address reached, what the page declared about itself, and how its host resolved at that moment, including its TLS certificate.
• Seconds after capture, DigiCert signs the SHA-256 of the document as an RFC 3161 timestamp. Only the fingerprint leaves our service. We renew the timestamp before its certificates expire, so it stays checkable for decades.
• Snapshots are never rewritten. Capturing again files a new snapshot beside the old one, and an activity log names who did what.
• You can check any capture yourself with OpenSSL, no account needed:

openssl ts -verify -data example.com-20260923-1600.html \
  -in example.com-20260923-1600.tsr -token_in \
  -CAfile /etc/ssl/certs/ca-certificates.crt

It prints Verification: OK only if the file, the signature and the certificate chain all agree. Change one byte of the document and it fails.

Sources

• Federal Rules of Evidence, Rule 901 and Rule 902, Legal Information Institute, Cornell Law School.
• Regulation (EU) No 910/2014 (eIDAS), Article 41, on the legal effect of electronic timestamps.
• RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).