A client sent me a signed supplier agreement last month with a note: "we changed one date in appendix 2, that's fine right?" The signature panel in their viewer still showed a green tick. In mine it said the signature was invalid. Both of us were looking at the same file.

That disagreement is the whole problem with PDF signatures, and it is worth understanding before it happens to a contract you actually care about.

A signature covers bytes, not meaning

When you sign a PDF, the signing tool does not sign the document you see. It signs a byte range — a start offset, a length, and usually a second range after a placeholder where the signature itself gets written. You can see it in the raw file:

grep -a "/ByteRange" signed.pdf

You will get something like [0 8432 12480 2100]. That means "these bytes, and then those bytes, but not the hole in the middle where my signature lives." Everything else in the file is covered. Anything that shifts those offsets changes the covered content.

This is why the same file can look fine in one viewer and broken in another. Some viewers only check that a signature exists and the certificate chains to a trusted root. Others check the byte range against the current file. The second kind is the one that matters.

Two ways to edit a PDF, two very different outcomes

PDF supports incremental updates. When you add a comment, fill a field, or drop in a new signature, a compliant tool appends new objects to the end of the file and leaves the original bytes untouched. This is why a PDF can carry its own history.

That has two consequences, and people usually only know one of them.

If the editor appends, the signature stays technically valid, because the original byte range is still intact. But now the file contains content the signature never covered. Someone can add a clause after the signature block and the signature still validates. Depending on the viewer, you get either a green tick or a vague warning about "changes after signing". Neither is reassuring if the change is a payment term.

If the editor rewrites the file, which is what most "Save as" flows and most online tools do, every offset moves. The signature is now over bytes that no longer exist. The signature becomes invalid, permanently. You cannot repair it. You can only re-sign.

Here is how to tell which one you are holding. Poppler ships a tool that reads the signature dictionary and reports both integrity and coverage:

pdfsig signed.pdf

The output separates "Signature Validation: Signature is Valid" from anything the file gained after signing. If it prints a second block saying the document was modified, that is the incremental case — signature intact, coverage gone. If the signature itself fails, the file was rewritten.

For the certificate side:

openssl pkcs7 -inform DER -in extracted_signature.der -print_certs -noout

That tells you who actually signed, which is not always who you think. I have seen a contract "signed by" a company where the certificate subject was an individual's personal email address, self-issued, not tied to the organisation at all.

What this looks like in practice

The pattern I run into most: a contract gets signed, then someone notices a typo in the entity name, opens it in an editor, fixes the typo, saves. The typo is gone, the signature is gone too, and nobody notices because the visual signature image is still sitting there on page 7. The image is a picture. It has nothing to do with the cryptography.

Second pattern: redlining after signature. Someone reopens the signed PDF, adds a comment "please confirm delivery date", saves with an incremental update. Now the file says it is signed, and also says something the signer never saw. If that ends up in a dispute, the other side will ask which version was signed, and you need an answer that is not "the one in the email thread somewhere".

Third pattern, and the one that actually causes losses: a "signature" that is an image pasted into the page. No certificate, no byte range, nothing to verify. It looks exactly like a real signature in a screenshot.

The boring workflow that avoids all of this

Sign last. Not "sign, then tidy up" — tidy up, then sign.

If you must change something after signing, re-sign and keep both files. The version numbering matters more than people think, because the audit trail is the deliverable, not the PDF.

Verify before you send, every time, with a tool that checks integrity rather than presence:

pdfsig final.pdf | grep -i -E "valid|modified|not verified"

If it says modified, you know you are sending a file whose signed content does not match its visible content. That is a conversation you want to have internally, not with a counterparty's lawyer.

And for anything with a legal consequence, decide up front whether you need a qualified signature or just an advanced one — that is a regulatory question under eIDAS in the EU and ESIGN in the US, and it changes both the tooling and what you can claim later. A scanned signature image is neither.

Why I care about this beyond contracts

I build PDF tooling, so I end up inspecting files that have been through four or five different editors. The signatures are almost always the first casualty, and the failure is silent. The document opens, the page looks right, the little signature graphic is still there. Nothing on screen tells you the cryptographic link is broken.

The only reliable check is the one nobody runs: read the file, not the page.

If you have a signed PDF open right now, run pdfsig on it. What does the integrity line say?