5 min readPrivacy and security
Use a fingerprint to check the exact file bytes
Learn what a PDF hash proves, why identical-looking files can differ, and how fingerprints fit contract, download, and evidence workflows.
The short answer
To prove a PDF has not changed, record a cryptographic hash of the file and compare it later with a new hash from the received or stored copy. Matching hashes show the bytes are identical. A hash does not prove who created the PDF, who approved it, or whether the contents are true.
- A PDF fingerprint is a cryptographic hash of the file bytes, so one changed byte produces a different result.
- Matching hashes prove file integrity for that exact copy, but they do not prove authorship, consent, or legal validity.
- Hashing is different from comparing PDFs visually and different again from applying a digital signature.
Sometimes the question is not what a PDF says. The question is whether the file you are looking at is exactly the same file that was sent, downloaded, archived, or submitted earlier. That is an integrity question, and it is different from metadata inspection, redaction, or visual comparison.
A PDF fingerprint answers that narrow question by computing a cryptographic hash of the file. If you hash the same file twice, you get the same value. If one byte changes, the value changes. That makes a hash useful for contracts, statements, evidence bundles, software manuals, policy documents, and any PDF where the exact copy matters.
The PDF fingerprint tool gives you that integrity check in the browser. It does not decide whether the document is truthful or legally valid. It tells you whether the file bytes match a recorded reference.
What a PDF fingerprint is
A fingerprint is the output of a hash function such as SHA-256. The input is the file's bytes. The output is a fixed-length string that looks like a long run of letters and numbers. It is designed so that a tiny change to the input produces a very different output.
That sensitivity is the point. If you record the hash of a signed contract at the moment you send it, you can later hash the returned file and compare the two values. If they match, the returned file is byte-for-byte identical to the copy you recorded. If they differ, something changed.
This is not the same as looking at the pages. Two PDFs can look identical and still have different hashes. A viewer can also show the same visible page while metadata, object order, compression, embedded fonts, or internal timestamps have changed underneath.
That difference sets the boundary of this article. If your question is what changed between two drafts, you want a content diff, and comparing two versions of a PDF is the guide for that. This post is about the narrower evidential question: proving that a specific file is byte-for-byte the one you approved, received, or signed.
Why visually identical PDFs can hash differently
A PDF is more than the page you see. It contains objects, streams, fonts, metadata, cross-reference tables, image compression, permissions, and sometimes incremental updates. A PDF reader may rewrite some of that structure when you save, optimise, print, repair, or add a note.
That means the same visible document can produce a different hash after a perfectly ordinary action. Opening a statement and choosing Save As may rewrite internal object numbers. Adding and deleting a blank annotation may leave an incremental update. A repair tool may rebuild the cross-reference table. A printer driver may create a fresh PDF that looks the same but contains different fonts and image streams.
The hash is not wrong in those cases. It is doing exactly what it should: it is checking the exact bytes, not the human impression of the page. If your question is whether the wording appears to have changed, use compare PDFs. If your question is whether this is the same file you recorded earlier, use a fingerprint.
What a hash proves and what it does not
A matching hash proves integrity for a specific file copy. It tells you that the bytes you have now match the bytes that were hashed before. That is powerful, but narrow.
A hash does not prove who created the PDF. It does not prove that the named person approved it. It does not prove that a signature is valid, that the content is accurate, or that the document was not already wrong when you first hashed it. If a tampered file is hashed and recorded as the reference, future matches only prove that the same tampered file has been preserved.
This is why you should record hashes at meaningful moments: when you send a contract, when you receive a final version, when you download a statement from a known source, or when evidence is first collected. The timing of the reference matters as much as the hash value.
How hashing differs from a digital signature
A hash and a digital signature are related but not interchangeable.
Hashing gives you a fingerprint. Anyone with the file can compute it. If two people compute the same hash for the same file, they should get the same result. There is no identity attached to the hash by itself.
A digital signature uses cryptography to bind a document to a signing identity and to detect later changes. Depending on how it is created and validated, it can answer broader questions about who signed and whether the document changed after signing. Use the sign PDF tool when the workflow needs approval or signing, not merely a file integrity check.
In practice, teams often use both. A signature supports authorship or approval. A recorded hash supports chain-of-custody notes, download verification, or a quick check that an attachment was not altered between systems.
Practical workflows for PDF fingerprints
For contracts, compute the hash of the exact PDF you send and store it beside the email, matter record, or deal folder. If someone later asks whether the file attached to a reply is the same version, hash the attachment and compare.
For downloaded statements, policies, or manuals, record the hash immediately after download if you may need to show that the archived copy has not changed. This is useful when the same filename is reused for monthly or revised files. The filename alone is weak evidence; the hash is tied to the bytes.
For evidence handling, record the hash before review work begins. Keep the hash with the date, source, collector, and storage location. If you must make working copies for annotation or redaction, hash those separately and keep the original reference untouched. A later mismatch then tells you which copy changed.
For team hand-offs, paste the hash into a ticket or case note along with the file name. Do not rely on file size alone. Two different PDFs can have the same size, and the same document re-saved by different tools can change size without changing visible content.
A short checklist
- Hash the file at the moment that matters, not days later.
- Store the hash value with the file name, date, source, and context.
- Compare hashes only when you need byte-for-byte identity.
- Use visual comparison when you need to inspect content differences.
- Use a digital signature when approval or signing identity matters.
- Expect a different hash after re-saving, repairing, annotating, or printing a PDF, even if the pages look unchanged.
Tools used in this guide
Each workspace runs in this browser tab. Open one directly to apply the steps above to your own document.
Written by The PdfEditorOnlineFree team. Published . Product behaviour described here reflects the linked workspaces at the time of review; check the tool page for current limits.