Hash value
A hash value is a fixed-length string computed from a file's contents by an algorithm such as MD5, SHA-1 or SHA-256. The same input always produces the same hash, and any change to the input produces an entirely different one, which is what makes hashes the fingerprints eDiscovery uses to deduplicate, de-NIST, and show that a file has not been altered since collection.
Also called: hash · MD5 · SHA-1 · SHA-256 · message digest · hash matching · checksum
Updated October 2, 2026
How does a hash value work?
A hashing algorithm reads a file’s bytes and produces a fixed-length output regardless of input size: a 4 KB email and a 4 GB video both yield a 32-character MD5. The properties that make it useful are determinism (the same bytes always give the same digest) and the avalanche effect (one changed byte changes roughly half the output bits).
eDiscovery uses this in four places. Deduplication keeps the first file of each hash and suppresses the rest. De-NISTing drops files whose hash appears in the NIST National Software Reference Library. Chain of custody records a hash at acquisition and re-verifies it at each transfer. And productions frequently carry an MD5HASH or SHA1HASH field in the DAT file, so the receiving party can confirm what it got.
Email is the exception. The same message exported from two mailboxes produces two different files and therefore two different hashes, so platforms compute an email hash over a canonical set of message fields (typically sender, recipients, subject, sent date and time, body and attachment hashes) instead of over the file. Which fields go into that calculation varies by platform, which is why the ESI protocol should say.
Hashes are computed on content only. Renaming a file, moving it, or changing its system metadata does not change its hash, which is exactly why the hash identifies the document while the metadata describes its circumstances.
What does a hash value look like in practice?
Digest lengths, with the digests of an empty file as a check anyone can reproduce:
| Algorithm | Bits | Hex characters | Digest of an empty file |
|---|---|---|---|
| MD5 | 128 | 32 | d41d8cd98f00b204e9800998ecf8427e |
| SHA-1 | 160 | 40 | da39a3ee5e6b4b0d3255bfef95601890afd80709 |
| SHA-256 | 256 | 64 | e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 |
The avalanche effect, on two strings differing by one character:
"Board deck v1" MD5 cde4b6af524450ee10be6ce8b5b86b00
"Board deck v2" MD5 0b1dd7607c54b83816a58a702d10c5b1
No part of the second digest resembles the first. That is why a hash comparison is a binary answer, matched or not, with nothing in between, and why near-identical documents need near-duplicate analysis rather than hashing.
Digest lengths per RFC 1321 and NIST FIPS 180-4; the digests above were computed directly and can be reproduced with any standard hashing utility.
How does a hash value show up on an eDiscovery invoice?
Hashing has no line of its own and should not. It is a step inside per-GB processing, and computing it costs a fraction of the time spent reading the file. Where it becomes a charge is indirectly: the reductions hashes enable (deduplication and de-NISTing) are sometimes billed as an ECA or culling fee per gigabyte, and sometimes bundled into a data enrichment line, which the Fee Field Guide records as a vaguely defined per-gigabyte charge for what are standard pipeline steps.
Hash fields also matter at the far end. A production that carries a hash field lets the receiving party verify delivery and deduplicate across productions; one that does not means paying to re-hash on the way in.
Ask whether hash generation and hash-based reduction are included in processing, and whether hash fields are exported by default or count as a custom field list.
Sources
- R. Rivest, RFC 1321, The MD5 Message-Digest Algorithm (1992).
- NIST FIPS 180-4, Secure Hash Standard.
- NIST announcement, December 2022, on the retirement of SHA-1 by 31 December 2030.
- Marc Stevens et al. (CWI Amsterdam and Google), SHAttered: the first practical SHA-1 collision (2017).
- NIST, National Software Reference Library, Reference Data Set documentation.
- Lorraine v. Markel American Insurance Co., 241 F.R.D. 534 (D. Md. 2007) (hash value as a distinctive characteristic under Fed. R. Evid. 901(b)(4)).
- Fee categories: the Fee Field Guide dataset.
Related terms
Deduplication · De-NISTing · Chain of custody · Processing · Collection · Metadata
eDiscovery at one flat monthly rate
$3,250 a month on a 12-month agreement. No per-user fees and no per-GB hosting charges.
Common questions
What is the difference between MD5 and SHA-1?
Length and strength. MD5, specified in RFC 1321, produces a 128-bit digest written as 32 hexadecimal characters. SHA-1, specified in NIST FIPS 180-4, produces 160 bits, written as 40 characters; SHA-256 produces 256 bits and 64 characters. Both MD5 and SHA-1 have been broken for security purposes, and NIST announced in December 2022 that SHA-1 would be phased out by 31 December 2030. For deduplication and identification in eDiscovery both remain in everyday use; for anything adversarial, SHA-256 is the answer.
Can two different files have the same hash?
Yes, that is a collision, and for MD5 and SHA-1 collisions can now be constructed deliberately. In 2017 researchers at CWI Amsterdam and Google published SHAttered, two different PDF files with the same SHA-1 digest. Accidental collisions between real documents remain vanishingly unlikely, which is why hash-based deduplication is not in practice a problem; deliberate collisions are why hashes alone are not a security control.
Does a hash value prove a file was not altered?
It proves the file is bit-for-bit identical to whatever was hashed before, if you have a trustworthy record of that earlier hash. The hash is only as good as the chain of custody it sits in. A hash recorded at acquisition and re-verified on receipt is evidence; a hash computed for the first time three months later shows only that the file has not changed since then.