Why Compressing a PDF Breaks the Signature

A digital signature on a PDF doesn't just sign the words on the page — it signs the exact sequence of bytes that made up the file at the moment you signed it. That signature is generated from a hash of a defined byte range, then embedded in the file alongside a record of what that range looked like. Compression works by re-encoding and rewriting the PDF's internal streams — images get recompressed, fonts get subset, object structures get rebuilt — to shrink the file. Even if the page renders identically afterward, the underlying bytes are now different from what was signed. When a PDF reader re-checks the signature, it recomputes the hash over the current bytes and compares it to the stored value. They no longer match, so the signature shows as invalid or modified, even though nothing about the visible content changed. PixelTools' own compressor only recompresses embedded JPEG images that shrink by at least 10% and skips CMYK images entirely, but it still rewrites the whole file on save every run, even if no image qualifies, which is exactly the step that breaks a signature.

This happens with essentially any PDF compression tool, not just PixelTools — Adobe Acrobat, online compressors, desktop optimizers, print-shop preflight software, all of it. It's not a flaw in the software; it's how PDF digital signatures are designed to work. The whole point of a byte-range signature is to detect any change to the file after signing, whether that change is malicious tampering or an innocent compression pass. If compression could silently preserve a valid signature, the signature would no longer be proof that the file hasn't been altered since it was signed. So the behavior you're seeing — a signed PDF coming out of a compressor as 'invalid' or 'modified since signing' — is expected, not a bug to report.

The only reliable fix is ordering: compress the PDF before it's signed, never after. Once a signature is applied, treat the file as final — any further processing, including compression, will invalidate it. If you're building a document that needs to be both small and signed, run it through a compressor while it's still an unsigned draft, confirm the file size and quality are acceptable, and only then apply the signature as the last step. In PixelTools' workflow that means: run your draft through /compress-pdf first, review the result, then open that compressed file in /sign-pdf to add your signature. Because the signature is applied to the already-compressed bytes, there's nothing left to shrink afterward, so nothing breaks it. This same rule applies to any other post-signing edit — adding pages, rotating, redacting — not just compression.

If the only copy you have is already signed and it's too large, you generally can't compress it without breaking that signature — there's no way to shrink the file and leave the original signed bytes untouched, because compression rewrites the very bytes the signature covers. The fix is to go back to the source: find the unsigned (or pre-signature) version of the document, run that through compression, and then re-sign the compressed result. If you don't have that earlier version — say the sender only gave you the final signed copy — you'll need to ask them for the pre-signed file, or accept that compressing it means the recipient will need a re-signed replacement rather than a smaller copy of what they already have.

A related mix-up: flattening a PDF isn't the same operation as signing it, but it follows the same ordering rule. Flattening takes fillable form fields and annotations and bakes them into the page as permanent, non-editable content — useful for locking in the values someone typed into a form before it moves on. If you're preparing a filled-out form for signature, flatten it first so the field values can't be altered after the fact, then sign the flattened file. Signing before flattening — or flattening after signing — runs into the same byte-range problem as compression: flattening rewrites the PDF's internal structure, so doing it after signing invalidates the signature just as compression does. The safe order is compress, then flatten, then sign, whenever more than one of these steps applies.

Putting it together, here's the order that avoids every version of this problem: 1) Start with your draft PDF, unsigned. 2) If it has fillable fields you've filled in, flatten it with /flatten-pdf to lock those values in. 3) Compress the file with /compress-pdf to get it down to size — check the output quality before moving on, since this is your last chance to re-run compression. 4) Only now, sign the compressed, flattened file using /sign-pdf. Because signing is the last operation in the chain, nothing downstream touches the file's bytes again, and the signature stays valid however the recipient opens or verifies it. Do these steps in any other order and you risk shipping a document whose signature reads as invalid.