How to prove a document hasn't changed

Six months after everyone signed, a dispute surfaces. The other side produces their copy of the agreement, and clause 7 doesn't say what you remember it saying. Both files are called agreement-final.pdf. Both look plausible. Neither of you is necessarily lying — files get re-saved, versions get muddled. Without something recorded at the time, "this is the document we agreed" is just two people's memories, and memories don't win arguments.

What a hash is

A cryptographic hash is a fingerprint for data. Feed a file to a hash function — SHA-256 is the sensible modern default — and it returns a fixed-length value, 64 hexadecimal characters, regardless of whether the input was one page or ten thousand.

Three properties make it useful:

It's deterministic. The same bytes always produce the same hash. Anyone, anywhere, on any machine, gets the identical value.
It changes completely on any edit. Alter a single character — a comma, one bit — and the output is entirely different. Not slightly different. Unrecognisably different. This is called the avalanche effect, and it's why hashes can't be "close".
It doesn't run backwards. You cannot reconstruct the document from the hash, and you cannot practically craft a different meaningful document that produces the same hash.

So the fingerprint is safe to share publicly. Publishing the hash of a confidential contract reveals nothing about its contents — but it pins the contract down.

The short version: a hash answers exactly one question — "are these two files byte-for-byte identical?" — and answers it definitively. Every other question you might want answered, it doesn't touch.

What a hash does not prove

This is where the idea gets oversold, so it's worth being precise. A matching hash tells you the file is unchanged. It does not tell you:

Who created it. A hash carries no identity. Anyone can hash anything.
When it existed. The value proves nothing about time on its own. A hash you compute today says today's file is today's file — a tautology.
That the contents are true, lawful, or agreed. A hash of a forgery is a perfectly valid hash of a forgery.

Hashes give you integrity, not authenticity. Conflating the two is the most common mistake in this area.

The part everyone gets wrong

A hash computed now proves nothing about the past. If you hash a file today and the value matches the file today, you've learned nothing — of course it matches; it's the same file.

A hash only becomes evidence when the value was recorded somewhere trustworthy before the dispute existed. The security doesn't live in the mathematics; it lives in the timeline. The question a hash answers is "does this match what we wrote down back then?" — and that requires that someone wrote it down back then.

Which makes the workflow, not the algorithm, the thing that matters.

A workflow that's actually worth something

Hash the file at the moment it becomes final. Right after signing, before it's filed away. Use Document Hash.
Record the value where it can't be quietly revised. Put it in the email that transmits the document. Read it into the minutes. Send it to the counterparty so they hold it too. The goal is a record with a date that isn't solely under your control.
Archive the exact file. Not a re-export. Not "the same document" printed again. The exact bytes you hashed.
Later, recompute and compare. Same value: byte-identical, no argument. Different value: the file changed, though not necessarily maliciously — see below.

Open the Document Hash tool

Why your hash changed when "nothing changed"

This trips people up constantly, and it's not a fault in the hash. A hash covers bytes, not appearance. Two PDFs can look pixel-identical and hash differently:

You re-saved it. Opening a PDF and exporting it again rewrites the file. New timestamps, possibly a new Producer, different internal structure. Identical to read, different bytes.
Something appended to it. PDFs support incremental updates — adding a comment or filling a field can append data rather than rewrite it. The document grew; the hash changed.
A tool touched it in passing. Some email systems and document managers rewrite attachments. The change may be entirely invisible and entirely real.

So a mismatch means "these are not the same file", not "someone tampered with this". The correct response is investigation, not accusation. And the practical lesson is firm: archive the file you hashed, and don't let anything re-save it.

Keeping a local record

If you routinely need to establish that documents haven't drifted, hashing each one by hand gets tedious. Local Signature Record keeps a record of documents you've hashed on your own device, so you have a personal log to check against later — without registering documents with any third party.

Be clear about what that is and isn't. It's a private, self-maintained record: strong for your own confidence, for internal process, for catching accidental drift. It's your record, though — you control it, which is exactly the limitation when the person doubting you is the person on the other side of the table.

When you need more than a hash

If a third party must be convinced, integrity alone won't get you there. You need something binding the document to an identity, and ideally to a time, in a way neither party controls:

A digital signature is a hash plus identity: the value is signed with a private key, so anyone with the matching certificate can confirm both that the file is unchanged and who signed it. That's why signatures require a trust chain and hashes don't — the hard part is proving whose key it is.
A trusted timestamp adds an authority's attestation that the hash existed at a certain moment, answering the "when" that a bare hash can't.
An exchanged hash is a decent middle ground: if both sides hold the value from the day of signing, neither can rewrite history unilaterally. No infrastructure, most of the benefit.

For internal records, personal archives and ordinary "is this the file I sent?" questions, a hash you recorded at the time is genuinely enough. For litigation, it isn't, and nobody should suggest otherwise.

A note on old algorithms

If you meet MD5 or SHA-1 in an existing process, treat them as checksums rather than security. Both have practical collision attacks: it's feasible to construct two different files with the same value, which is precisely the property you were relying on. They're fine for spotting accidental corruption and unfit for anything adversarial. SHA-256 is the default for good reason.

Why compute it locally?

Uploading a document to a website to learn its fingerprint gives a copy of that document to a third party — for a calculation your own device can perform in a moment. If the file matters enough to be worth pinning down, it matters enough not to hand out. In CyvoDocOps, supported operations of this kind run locally in your browser and the document is not uploaded to a server.

Frequently asked questions

What is a file hash in plain terms?

A short fingerprint derived from a file's contents. Same file, same fingerprint; change anything at all and the fingerprint changes completely.

Can two different documents have the same hash?

In theory yes, in practice not with SHA-256 — nobody can construct such a pair. With MD5 or SHA-1, yes, and that's why they shouldn't be used where it matters.

Does a hash prove who wrote the document?

No. It proves the file hasn't changed. Identity requires a digital signature, which binds a hash to a key belonging to a known person or organisation.

My hash changed but the document looks identical. Was it tampered with?

Not necessarily. Re-saving, filling a form field, or a system rewriting the attachment all change the bytes without changing the appearance. It means the file differs — worth investigating, not proof of bad faith.

Does the file get uploaded to be hashed?

No. The hash is computed locally in your browser and the document is not sent to a server.