Why Hashing Matters for Digital Evidence

October 13, 2026

Every serious piece of digital evidence travels with a string of letters and numbers that most people in the courtroom never read: its hash value. A forensic image of a phone has one. So does a properly preserved web page, an email export, a video file. Courts have called hash values digital fingerprints, and one of the two Federal Rules of Evidence written specifically for electronic evidence rests on them.

In short, a hash lets anyone prove that a copy is identical to what was collected. That is what makes a chain of custody checkable, and it is what a Rule 902(14) certification rests on. This guide explains, without the math, why the hash value is so important in digital forensics: what it proves, what it cannot prove, which algorithms to trust, and how to check one yourself in under a minute.

The four properties that make a hash useful

A hash function reads every bit of a file and produces a short, fixed-length string from it. The common one today, SHA-256, always produces 64 characters, whether the file is a two-line text message or a 2 GB video. The Advisory Committee note to Federal Rule of Evidence 902(14) describes it as “a number that is often represented as a sequence of characters,” produced “by an algorithm based upon the digital contents of a drive, medium, or file.”

Four properties make that useful as evidence:

1. Same input, same output. Hash the same file today and in ten years, on any computer, and you get the same value.
2. Any change, a different value. Change one comma, one pixel, one bit, and the hash changes completely, not slightly.
3. One way only. You cannot rebuild a file from its hash, though anyone holding a candidate file can check whether it matches.
4. No practical look-alikes. With a modern algorithm like SHA-256, nobody knows a practical way to make two different files with the same hash, let alone one that matches an existing file. Older algorithms like MD5 and SHA-1 have lost the first protection but not the second, as explained below.

Put together, a hash is a compact way to say “this exact file, and nothing else.”

Why hash values matter in digital forensics

They prove a copy matches the original

Most digital evidence is a copy: an image of a hard drive, an extraction from a phone, a capture of a web page. The hash is how anyone can check that the copy is faithful. The committee note to Rule 902(14) says it directly: “If the hash values for the original and copy are the same,” then “it is highly improbable that the original and copy are not identical.”

They make the chain of custody checkable

A chain of custody is a record of who had the evidence and what they did with it. A hash turns that record into something testable. Compute it when the evidence is first collected, record it, and check it again after every copy or transfer. NIST’s forensic guidance, SP 800-86, describes exactly this: compute the digest of the original and of the copy, then compare them. The digital evidence standards group SWGDE recommends that “hashes be made as early as possible during the collection process.” If the value ever changes, something changed. If it never does, nothing did. Our guide to chain of custody for digital evidence covers the rest of that record.

They let copied data authenticate itself

Rule 902(14), added in 2017, makes data copied from a device, storage medium or file self-authenticating “if authenticated by a process of digital identification,” shown by a qualified person’s certification. The party offering it must give the other side written notice before the trial or hearing and let them inspect the data and the certification. The committee note says such data is “ordinarily authenticated by ‘hash value,’” and the rule settles authenticity only; every other objection stays open. Before that rule existed, courts already treated hashes as authentication evidence. In Lorraine v. Markel American Insurance Co., 241 F.R.D. 534 (D. Md. 2007), the court wrote: “One method of authenticating electronic evidence under Rule 901(b)(4) is the use of ‘hash values’ or ‘hash marks’ when making documents,” quoting a definition that likens hashing to a digital Bates stamp. The certification route is explained in FRE 902(13) vs 902(14).

Courts trust them

In United States v. Holmes, 121 F.4th 727 (9th Cir. 2024), the Ninth Circuit noted that “courts have equated hash-value matches to digital fingerprints or digital DNA.” Then-Judge Gorsuch, writing for the Tenth Circuit in United States v. Ackerman, 831 F.3d 1292 (10th Cir. 2016), explained that a hash is calculated “in a way that makes it highly unlikely another set of data will produce the same value.” Those statements come from search-and-seizure cases rather than authentication disputes, but they show how settled the reliability of hash matching has become.

They save time

Investigators also use hashes to skip what does not matter. NIST’s National Software Reference Library publishes hash values of known software files, so an examiner can set aside thousands of ordinary system files at once and focus on what is left.

What a hash cannot prove

A hash is precise about one thing and silent about everything else. Knowing the limits is what keeps it from being oversold, by you or by the other side.

• It does not prove the content is true or genuine. A hash shows a file has not changed since the hash was computed. A fabricated screenshot, hashed today, will match its own hash every time it is checked.
• It only covers the time after it was computed. A hash taken the day of collection protects the evidence from that day on. A hash taken three weeks later says nothing about what happened in those three weeks. SWGDE makes the same point: hashing does not protect against changes made before the hash was taken. The moment of hashing matters as much as the hash.
• It does not say when. A hash value carries no date. To prove a file existed by a certain time, the hash itself has to be anchored in time by someone else: an RFC 3161 timestamp from a timestamping authority, or a Bitcoin-anchored timestamp such as an OpenTimestamps proof. Without that, a hash proves “unchanged since then” with no reliable “then.”
• It does not say who. Nothing in a hash identifies the author of a file or the person who collected it. Authorship is proved with other evidence.
• It does not recognize near-copies. A screenshot re-saved in a different format, or a photo shrunk for email, has a completely different hash, even though it looks the same. Tools that match similar-looking images, such as PhotoDNA, are a different technology with different strengths; the Sixth Circuit noted in United States v. Miller, 982 F.3d 412 (6th Cir. 2020), that such tools can return the same value “even if a file changes slightly.”

Which algorithms to trust

SHA-256 is the standard choice for new work. It belongs to the SHA-2 family that NIST publishes in FIPS 180-4. The newer SHA-3 family, in FIPS 202, is equally sound.

MD5 and SHA-1 are older and weaker. Researchers published MD5 collisions in 2004, and in 2017 Google and CWI Amsterdam released two different PDF files with the same SHA-1 hash. NIST announced in December 2022 that “SHA-1 should be phased out by Dec. 31, 2030,” and recommends moving to SHA-2 or SHA-3.

A collision is usually not a forgery of your evidence. Those attacks let someone create two new files that share a hash. They do not let anyone make a different file that matches the hash of an existing one. SWGDE’s position paper puts it plainly: such an attack “cannot be used to create a different file whose hash matches a pre-existing file’s hash,” and it treats MD5 and SHA-1 as still acceptable for integrity verification when the hash is securely recorded. The exception is a file prepared by someone who could have made two versions in advance, and SWGDE accepts only SHA-2 or SHA-3 when a hash match stands in for looking at the file itself. So an MD5 or SHA-1 value on an older forensic image is not worthless, but for anything collected now, use SHA-256, and be ready to explain the difference if the other side raises an older algorithm.

How to check a hash yourself

You do not need forensic software. Every computer can do it:

• Mac: open Terminal and run shasum -a 256 filename. Include -a 256, because without it shasum uses SHA-1.
• Linux: run sha256sum filename.
• Windows: in PowerShell, run Get-FileHash filename, which uses SHA-256 by default. In Command Prompt, run certutil -hashfile filename SHA256.

If the file name contains spaces, put it in quotes. Then compare the result with the value recorded when the evidence was collected. Capital and small letters count as the same, and any spaces between characters can be ignored, because different tools print the same value differently. Every character must otherwise match. One character off means a different file.

A short checklist for hashing evidence properly

1. Hash at the moment of collection, before anything else touches the file.
2. Use SHA-256, and record the algorithm along with the value.
3. Record who computed it, when, and how.
4. Re-check the hash after every copy or transfer, and record each check.
5. Anchor the hash in time with an independent timestamp, so the record proves when as well as what.
6. Keep the original and the hash record somewhere that will outlast the case.
7. Make it checkable by the other side without anyone having to trust you.

Where Permavault fits

Permavault applies that checklist to every capture by default. When a web page is captured or a file is uploaded, every file is hashed with SHA-256 the moment it is received, the list of hashes is signed with an Ed25519 key, and the signed record is timestamped independently. Everything is stored on a permanent decentralized network of roughly 300 independent nodes, funded by a long-term storage endowment. Anyone can check a capture without trusting us: our verification page looks up its record, and each evidence package includes a script that rechecks every hash and the signature with free standard tools, as our guide to verifying a WACZ capture walks through.

Each capture is $4.99, down to $2.98 with a pack, and carries an independent Bitcoin-anchored timestamp. An optional $9 Certificate of Authenticity documents the capture process. The Legal certificate ($39) adds an RFC 3161 timestamp on the signed capture manifest, a chain-of-custody appendix, and a declaration template designed to support authentication under FRE 902(13) and 902(14). The Legal evidence package states whether the timestamp qualifies under eIDAS.

This article is general information, not legal advice for any specific matter. Technical standards described here reflect NIST and SWGDE publications as of October 2026. Admissibility always depends on the facts, the jurisdiction, and the judge.