A client’s screenshots arrive by email, opposing counsel’s production lands on a download link, and an expert report cites a 64-character string as proof that a phone image is unchanged. Hash values now show up across ordinary civil and family litigation, and anyone on your team who handles digital evidence should be able to explain what one proves, compute one, and recognize when one is being stretched past what it can show.
The short version: a hash value proves that two files are bit-for-bit identical. It does not prove who created a file, when it was created, or whether what it shows is true. This guide covers the mechanics in plain English, where hashes are useful, how to compute them with tools already on your computer, a log format, and the mistakes that weaken them.
What is a hash value, in plain English?
A hash value is a fixed-length code calculated from every bit of a file by a published mathematical function. Feed the same file in and you always get the same code; change anything in the file and you get a completely different one.
SHA-256, part of the SHA-2 family published by the National Institute of Standards and Technology, produces a 256-bit value that is usually displayed as 64 hexadecimal characters (0–9 and a–f). Its useful properties for litigation are:
- Deterministic. The same input always produces the same value, on any computer, with any compliant tool.
- Sensitive. Changing one character, one pixel or one byte of metadata produces an unrelated value, not a slightly different one.
- One-way. You cannot reconstruct a file from its hash, so a list of hash values does not disclose what the files say, though anyone holding a copy of a file can check whether it matches.
- Collision-resistant. No two different files have ever been publicly shown to share a SHA-256 value.
A concrete illustration: the SHA-256 value of a completely empty file is always e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, on every machine, every time. Add a single space to that file and the value changes entirely.
What does a hash value prove, and what doesn’t it?
A matching hash proves identity between two files. Everything else has to come from somewhere else.
| A matching hash shows | A hash does not show |
|---|---|
| The produced copy is identical to the file preserved at intake | That the content is accurate or truthful |
| A file has not changed since its hash was recorded | That the file was unaltered before the first hash |
| Two documents are exact duplicates | That two documents are similar (one changed pixel means no match) |
| A forensic copy matches the acquired source data | Who created, sent or edited the file, or when |
The second row is the one that matters most in practice. A hash protects the file from the moment it is first recorded. If a client edited a screenshot before sending it, a hash computed on arrival faithfully preserves the edited version. That is why hashing belongs at the very front of intake, and why it works alongside, not instead of, a documented chain of custody for digital evidence.
Where do hash values show up in litigation?
Hashes appear wherever someone needs to show that a file is the same file it was earlier, or to identify identical files at scale.
- Intake integrity. Hashing client files on arrival creates a baseline for everything that follows.
- Production verification. A manifest of hash values lets the recipient confirm files arrived intact and gives the producing party a record of exactly what was sent.
- Deduplication. Review tools use hashes to suppress exact duplicates. See deduplication and threading for message reviews.
- Forensic acquisition. Examiners hash device images and extracted data so copies can be verified against the source.
- Self-authentication. Federal Rule of Evidence 902(14) allows hash-verified copies of data to be authenticated by certification, with notice. The guide to Rules 902(13) and 902(14) covers the requirements.
- Clawbacks and returns. Hash values identify exactly which files must be returned or destroyed under a protective order.
How do you compute a SHA-256 hash on any computer?
Every major operating system can compute SHA-256 with a built-in command. Open the terminal or command window, run the command with the file path, and record the output.
Built-in commands
macOS (Terminal): shasum -a 256 "/path/to/file.pdf"
Windows (PowerShell): Get-FileHash "C:\path\to\file.pdf" -Algorithm SHA256
Windows (Command Prompt): certutil -hashfile "C:\path\to\file.pdf" SHA256
Linux: sha256sum "/path/to/file.pdf"
Some tools print the value in uppercase letters and others in lowercase. The value is the same either way. When comparing, never eyeball 64 characters. Paste both values into a spreadsheet and compare the cells with a formula, or let your review or forensic tool do the comparison.
How should a firm log hash values?
A hash value is only useful if someone recorded it, with context, at a known time. A simple log makes every later comparison possible.
Template: hash log fields
Item ID / Original file name / Source (who provided it, how) / Date and time received / Algorithm / Hash value at receipt / Recorded by / Storage location of the original / Later verifications (date, purpose, value, match yes or no) / Bates range or exhibit number, if produced or offered
Here is how one file’s entries might read across the life of a matter:
Example: one screenshot, start to finish
March 3: client uploads IMG_4471.PNG through the portal; SHA-256 recorded at receipt; original stored read-only. March 10: paralegal makes a working copy for review; copy verified against the receipt value, match. April 2: image placed into a PDF exhibit set; the PDF is a new file, so its own SHA-256 is recorded and cross-referenced to IMG_4471.PNG. April 20: before the hearing, the original is re-verified, match, and the exhibit PDF is verified against its production value, match.
Each entry answers a question someone could ask later: what arrived, when, from whom, and whether anything changed between that moment and the hearing.
- Hash every original on arrival, before anyone opens, converts or annotates it
- Store the original read-only and work from copies
- Re-verify before production and before the hearing
- Hash each production file and include the values in a manifest
- Record the algorithm alongside every value
What are the most common hash value mistakes?
Most hash problems come from expecting a hash to survive a change that, by design, it cannot survive.
Hashing after conversion
Converting an iPhone HEIC photo to JPEG, printing an email to PDF, or optimizing a scan all create new files. Hash the original first, then hash any converted version separately and record the relationship between them.
Files that passed through messaging apps
Photos sent through many messaging and social platforms are compressed and often stripped of metadata on the way. The received file is a new file. If the original matters, collect it from the device that took it; the guide to preserving photo metadata explains why.
Expecting identical emails to hash identically
The same email exported twice, or saved from two different mailboxes, often produces two files with different hashes because headers, formatting or container details differ. Many review platforms therefore deduplicate email with a hash calculated from selected fields (sender, recipients, date, subject, body, attachments) rather than the whole file. Know which method your tool uses before describing results as exact duplicates.
Mixing algorithms
An MD5 value and a SHA-256 value of the same file will never match because they are different functions. Agree on the algorithm with the other side, or record both.
Overstating what the hash shows
A hash value is not evidence of authorship or timing. Pair it with testimony, metadata and logs that answer those questions.
How do you explain a hash value to a judge?
Keep the explanation short, concrete and limited to what the hash actually shows. Overclaiming invites a cross-examination you do not need.
Sample wording
“A hash value is a code calculated from every bit of a file. If even one character of the file changes, the code changes. We calculated this file’s code when it arrived on [date] and recorded it in our intake log. We calculated it again on [date] and the codes match, which shows this is the same file we received, unchanged.”
Systems that hash at the moment of upload remove the most common gap in this story, the delay between receipt and the first hash. Evidence Helper, for example, preserves each original untouched and records its SHA-256 value on arrival; see how originals are preserved and hashed. Whether a particular hash record is enough for a particular foundation remains a call for the responsible attorney, licensed in the jurisdiction where the matter is pending.
