What a file hash proves
A cryptographic hash reduces a file of any size to a short fixed-length string. The useful property is that changing anything at all in the file — a single character, a single pixel, one byte of metadata — produces a completely different hash, and it is computationally infeasible to construct a different file that produces the same one.
That gives you a precise answer to a narrow question: are these two files byte-for-byte identical? Matching hashes mean the file has not changed. Different hashes mean it has, even if the change is invisible when you look at the pages.
It is worth being clear about what this does not establish. A hash says nothing about who wrote a document, whether its contents are true, or when it was created. It is a check on integrity, not on authorship or authenticity, and it only means anything if you obtained the reference hash from a source you trust.
When comparing hashes is the right tool
The everyday use is verifying that a file arrived intact. Download a large document over a poor connection and a hash comparison tells you definitively whether it is complete, where a visual check would not catch a truncated final page or a corrupted image.
It is also the practical way to detect tampering in a document you circulate. Record the hash of the contract you sent, and if a signed copy comes back you can establish immediately whether the body was altered. This is a common step in legal and procurement workflows precisely because it is unambiguous.
And it settles the everyday confusion of near-duplicate files. Two documents with different names and different dates, sitting in different folders — are they the same document or two versions? Compare the hashes and you have a definite answer in seconds, rather than reading both.
Why identical-looking documents produce different hashes
This surprises people constantly, so it is worth explaining. Print the same document to PDF twice and the two files will almost always have different hashes, because the PDF records a creation timestamp and often a unique document identifier. The pages are identical and the files are not.
The same applies to a document that has merely been opened and saved by a different reader, or had its metadata cleaned, or been optimised. None of those change what you read; all of them change bytes, and therefore the hash.
So a hash mismatch is not proof that content was altered — it is proof that the file was. When a mismatch appears and you need to know whether the substance changed, compare the extracted text or run a visual comparison. The hash tells you to look; it does not tell you what you will find.
Using hashes as part of a document workflow
The habit that makes hashes useful is recording them at the moment a document becomes final, rather than trying to establish integrity after a dispute has started. A hash noted in a project log, an email or a case file at the point of sending is evidence; one computed afterwards proves only what the file is now.
For teams handling documents that matter, it is worth recording the hash alongside the filename and the date in whatever system already tracks the work. It costs seconds and turns questions like whether the version in the archive matches the version that was signed into a matter of fact rather than recollection.
The one thing to be careful about is comparing like with like. Hash the exact file you sent, not a copy that has been through a mail system that re-encoded attachments, and not a version re-saved by a reader. Otherwise the mismatch you eventually find will be your own workflow rather than anybody's tampering.