Someone hands you a saved web page and a long string of letters and digits labelled "SHA-256". The other side asks what that string proves. If your answer is "that it's authentic", you have overclaimed, and a careful opponent will say so.
A hash proves one thing, and proves it well. It does not prove several things people assume it does. This article sets out both lists, shows how to check a hash yourself, and says what to pair it with so the whole capture holds up.
What a hash is
A SHA-256 hash is a fixed-length fingerprint of a file: 64 hexadecimal characters, whatever the size of the file. FIPS 180-4, the US federal standard that defines the SHA family, describes these algorithms as producing a condensed representation of data.
The security of the fingerprint rests on properties that NIST lists for approved hash functions. It is "computationally infeasible to find two different inputs to the hash function that have the same hash value", and equally infeasible to construct an input that matches a hash you were given. NIST rates SHA-256 at 128 bits of collision resistance and 256 bits of preimage resistance, and it remains an approved algorithm.
In practice: change one character in a file and the hash changes completely. Finding a different file with the same hash is, by NIST's measure, computationally infeasible.
What a hash proves
This file is the same file. If the hash you compute today matches the hash recorded earlier, the file is, byte for byte, the file that was hashed then. That is the whole claim, and it is strong.
US courts recognise it. The Advisory Committee note to Federal Rule of Evidence 902(14), added in 2017, describes a hash value as a number produced by an algorithm from the contents of a drive, medium or file, and says that identical hash values for an original and its copy reliably show they are exact duplicates. The rule lets such a comparison, certified by a qualified person, authenticate the copy without a live witness.
Read that carefully. The rule is about whether a copy matches its source file. It does not say the source file is a true record of a web page.
What a hash does not prove
That the content is genuine
A hash of a forged page is a perfectly good hash. If someone edits a saved page and then hashes it, the hash matches the edited file every time you check it. The hash vouches for the file from the moment it was hashed, not for how the file came to exist.
Authenticity comes from how the capture was made: by whom, with what tool, from which address. We cover what to record in how to preserve a web page as evidence.
When the file was made
A hash contains no date. The same file has the same hash on any day. A date shown next to a hash is a claim by whoever wrote it down, and a file's own timestamps change when it is copied.
To fix a date, you need a statement from a third party that a file with this hash existed at a given moment. That is what an RFC 3161 timestamp is, and we show how to verify one with OpenSSL.
That the hash itself is the original
If the hash sits in the same folder, spreadsheet or database as the file, whoever can change the file can change the hash. A matching pair proves nothing about the order of events. The hash needs to be recorded somewhere the file's custodian cannot quietly rewrite, which is another job for an independent timestamp.
That the page said this to everyone
A hash covers the bytes you saved. Sites serve different content by location, device, language and login, and some pages change on every load. The hash cannot tell you whether a visitor in another country saw the same thing.
That two captures of the same page match
Because one changed byte gives a different hash, two captures of one unchanged-looking page will often differ: a rotating banner, a session identifier, a timestamp in the footer. Different hashes tell you the files differ, not that the page changed in a way that matters. To see what changed, compare the text of the two captures.
That it is the original and not a converted copy
Print the saved page to PDF, open it in an editor and save, or compress it into an email attachment that rewrites it, and you have a new file with a new hash. Hash the original at the moment it is created, keep that file untouched, and work from copies.
How to check a hash yourself
You need the file and the hash that was recorded for it. On Linux:
sha256sum example.com-20260923-1600.html
On macOS, use shasum -a 256 instead. Both print the hash followed by the file name. Compare it with the recorded value. They must match in every character. If they do, the file is unchanged. If they don't, it has been altered, re-saved or corrupted, and the hash alone cannot say which.
Which algorithm
Use SHA-256 or stronger. NIST deprecated SHA-1 in 2011 and disallowed it for digital signatures from the end of 2013, and in December 2022 published a plan to retire its remaining uses. If a record offers only a SHA-1 value, treat it as weak and, if you hold the file, compute a SHA-256 now and keep that as well.
What to pair a hash with
| You want to show | The hash alone | Add |
|---|---|---|
| The file is unchanged | Yes | Keep the original file read-only |
| When it existed | No | An independent RFC 3161 timestamp over the hash |
| Where it came from | No | The requested and final addresses, and the tool used |
| Who captured it and why | No | A dated log and a short note |
| What changed between two dates | No | A series of captures, compared as text |
How Archivepanel uses hashes
Archivepanel hashes the saved page when the capture finishes. The JSON manifest that sits alongside each capture lists a size, a SHA-256 digest and a content type for every file. DigiCert's RFC 3161 timestamp covers the SHA-256 digest of the stored document, so the record shows the file existed by the signed time. Only the digest is sent to DigiCert, never the page. Anyone with the downloaded document and its timestamp token can check them with OpenSSL, without an account. See trusted timestamps.
That gives you the first two rows of the table. It is a DigiCert timestamp, not an eIDAS qualified one. It also covers public pages only, and a hash proves nothing about what the site would have shown a different visitor.
Sources
- NIST FIPS 180-4, Secure Hash Standard (SHS).
- NIST Computer Security Resource Center, Hash functions: security properties, SHA-256 strengths and the SHA-1 transition.
- Federal Rules of Evidence, Rule 902, including 902(13) and 902(14) and the 2017 Advisory Committee note, Legal Information Institute, Cornell Law School.
- RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).