How can I prove a PDF has not been altered?

Why the obvious methods fail

Three approaches come up first, and all three are weaker than they look.

File metadata. Opening the document properties and comparing the creation date with the modified date feels like a check. It is not. Downloading a file can update its modification time without a single byte changing, and many editing tools leave the producer and creator fields untouched. Metadata is written by whoever last held the file, which is precisely the party whose behaviour is in question.

PDF/A conformance. PDF/A is an archiving format. It removes features that could make a document render differently in the future, such as embedded scripts and external font references. That is valuable, and it says nothing at all about whether the content changed. A PDF/A file can be edited and re-saved as a perfectly conformant PDF/A file.

A visible signature image. A scanned signature pasted into a document is a picture. It carries no cryptographic relationship to the bytes around it.

What actually works

Three mechanisms, and they answer three different questions. Leaving one out leaves a hole.

1. A cryptographic hash, to detect change. A hash function reduces the file to a fixed-length fingerprint. Change one bit anywhere and the fingerprint changes completely. SHA-256 or SHA-384 are the current sensible choices. The hash proves that the file you hold now is byte-for-byte the file the hash was taken from.

On its own it proves nothing about when, and nothing about who took it. A hash you calculated yourself and stored in your own database is still your word for it.

2. A trusted timestamp, to fix the moment. RFC 3161 defines how to send a hash to a Timestamp Authority and get back a signed token containing that hash and the time. Only the hash travels, so the document itself never leaves your systems.

This is the part that turns your own assertion into third-party evidence, because the attestation is signed by somebody who has no stake in your document.

3. A custody record, to cover the gap. The hash and the timestamp prove the state of the file at one moment. An auditor asks about the period between that moment and today. A custody record answers it: every action on the document, who performed it, when, and from where, written append-only so that entries cannot be quietly removed.

Chaining each entry to the hash of the previous one means a deletion in the middle breaks the chain, which is what makes the absence of tampering demonstrable rather than merely asserted.

What to keep, in practice

Keep the document, the hash, the timestamp token, and the custody record together. Keep them in a format you can still open in ten years, which in practice means PDF/A-3 for the document, because it permits attachments and can carry the evidence alongside the file.

Keep the verification material too. A timestamp token is verified against the Timestamp Authority’s certificate chain, and certificates expire. If you want to verify in 2035 what you timestamped in 2026, you have to preserve the chain and the revocation status as they were at the time. That material is available today and will not be available later.

Where SealDoc fits

SealDoc automates the three mechanisms above. Every document it processes becomes a PDF/A-3B file validated against ISO 19005-3, timestamped by default with RFC 3161, with a SHA-384 hash chain and a chain-of-custody record. It exports as an evidence pack per document, on request: the document, the audit trail and a manifest that seals both the individual files and the set.