Redacting a Digitally Signed PDF: Why It Breaks the Signature (and What to Do Instead)

By the SladdPDF team · Published September 9, 2026 · Updated September 9, 2026

Redacting a digitally signed PDF invalidates the signature. That is not a bug in a particular tool — it is how PDF digital signatures are designed to work under ISO 32000-2 and the PAdES standard (ETSI EN 319 142): the signature is a cryptographic hash over the exact bytes present when it was applied, so changing so much as one pixel behind a redaction box breaks it. If you need both a clean release copy and a document that still verifies, the redaction has to happen before the signing, not after.

What does a PDF digital signature actually sign?

A PDF digital signature is not a picture of a signature pasted onto a page — that's a stamp or an image, and it proves nothing. A real digital signature, as defined in ISO 32000-2 (the ISO standard for PDF 2.0) and profiled for European use by ETSI's PAdES standard (EN 319 142), works by taking a cryptographic hash of a specific byte range of the file and encrypting that hash with the signer's private key. The signature dictionary records exactly which bytes were covered.

When a viewer checks the signature, it recomputes the hash over that same byte range and compares it to the decrypted value. If they match, two things are confirmed: the file has not changed since signing, and the signature came from whoever holds the matching private key (assuming the certificate chain checks out).

This is fundamentally different from an "electronic signature" in the everyday sense — a typed name, a scanned wet-ink signature, or a click-to-sign checkbox. Those can be embedded as ordinary page content with no cryptography behind them at all. A document can look signed and not be digitally signed in the ISO 32000-2 sense; only the latter breaks when you redact it, because only the latter is actually bound to the file's bytes.

Why does redacting a signed PDF invalidate the signature?

Because redaction is a content change, and the signature's hash covers content. It does not matter which redaction technique you use:

• Drawing a black box on top of the text adds a new annotation object to the file — bytes that were not part of the hash at signing time. (It also, separately, is not real redaction, since the text usually survives underneath.)
• Deleting the underlying text object changes the page content stream itself.
• Rasterizing the page — the gold-standard approach for actually destroying redacted content — replaces the entire page with a new image object, which is the largest possible content change.

All three modify bytes the signature covers, so all three produce the same result in a viewer: a warning that the document has been altered since it was signed, and a signature marked invalid. There is no redaction method — vector or raster — that can remove content and leave a prior full-document signature intact, because "leave the signature intact" and "remove this content" are contradictory requirements on the same bytes.

Can a certification signature allow changes? What DocMDP does and doesn't cover

PDF distinguishes two kinds of signature. An approval signature is an ordinary signature — anyone can add one, and multiple people can sign in sequence. A certification signature is special: it must be the first signature applied to the document, and it can carry a DocMDP (Document Modification Detection and Prevention) permission that pre-authorizes specific kinds of later changes without invalidating itself.

ISO 32000-2 defines three DocMDP permission levels:

Notice what's missing: none of the three levels authorizes deleting or replacing page content. Filling a form field or adding a comment does not touch the existing content stream; redacting does. So even the most permissive certification signature (P=3) does not, and cannot, survive a redaction pass — DocMDP was designed to let people fill out and countersign a certified form, not to let anyone quietly cut content out of it later while the original certification still reads as valid.

In practice, most PDF viewers implement this conservatively too: Adobe Acrobat, for example, treats form-filling and annotation as the only changes a certified document tolerates, and flags essentially any other edit — redaction very much included — as breaking the certification.

Does rasterizing a signed PDF avoid the problem?

No — and it shouldn't try to. Rasterization is still the right way to redact a page, because it is the only method that reliably destroys the text layer, hidden objects, and anything sitting behind the visible redaction box. But rasterizing a signed page is exactly as much of a content change as any other edit, so it invalidates the signature exactly the same way.

The one class of change that genuinely does not break a signature is adding data to the document's Document Security Store (DSS) or a document timestamp — infrastructure PAdES uses for long-term validation, added as an incremental update that ISO 32000-2 explicitly carves out as not counting as a modification. That carve-out exists to let a signature stay verifiable for years after the signing certificate expires. It has nothing to do with redacting page content, and no comparable carve-out exists for content edits.

The right order: redact first, then sign

Once you accept that redaction and signature preservation cannot both apply to the same signed bytes, the fix is a process fix, not a tooling fix:

1. Work out who needs to see the signed original, and who needs the redacted copy. The party who is entitled to the full record (a court, a counterparty, an auditor) gets the originally signed file, untouched. Everyone else gets a separate, redacted copy.
2. Redact before anyone signs, whenever the workflow allows it. If a contract, affidavit, or form is going to be shared with a third party in redacted form, prepare and finalize the redacted version first, then route it for signature. The resulting signature covers exactly the bytes the recipient will see — no conflict.
3. If the document is already signed and must be redacted anyway, treat the redacted output as a new, unsigned copy — and have the correct party sign it again if a signature is still required on the released version. Keep the original signed file as your unaltered record of what was actually executed; the redacted copy is a derivative document with its own, later signature (or no signature, if none is required for that release).
4. Never try to "fix" an invalidated signature after redacting. There is no legitimate way to restore validity to a signature over bytes that no longer exist. A tool that appears to do so is either not actually redacting the content or not actually re-checking the hash.

Special cases: court filings, notarized deeds, and long-term validation

A few contexts make this collide with a real deadline:

• E-filed court documents. Federal courts require personal identifiers to be redacted under Federal Rule of Civil Procedure 5.2 before a document reaches the public PACER/CM-ECF docket — see our guide to redacting a filing for PACER. A digitally signed affidavit or declaration filed under this rule is redacted for the public record while the signed original is retained in the case file; the public copy is not expected to carry the original cryptographic signature.
• Notarized deeds and mortgages. A deed becomes a public record once recorded, and SSNs and account numbers are routinely redacted before recording or before sharing a copy. If the instrument carries a digital (not just notarized-ink) signature, the same rule applies: redact the copy meant for wider circulation, keep the notarized original intact.
• Long-term validation (LTV). PAdES defines profiles (B-LT, B-LTA) specifically so a signature stays checkable years later, after certificates expire — by embedding revocation data and timestamps. None of this machinery helps redaction; it solves a different problem (staying verifiable over time), and it still breaks the moment page content changes.

A practical workflow for a signed document that needs redaction

When you're handed an already-signed PDF and asked to release a redacted copy of it:

1. Confirm the file is actually digitally signed, not just typed or image-stamped. Most PDF viewers show a signature panel; if there is no cryptographic signature to check, none of the above applies and you can redact normally.
2. Keep the signed original untouched in your records. It remains the authoritative, verifiable copy.
3. Work on a copy in a redaction tool that runs locally in your browser, so the signed file never has to be uploaded anywhere just to black a few lines out of it.
4. Draw boxes over everything that must go, then export in Secure mode so the page is rasterized and the underlying text and any hidden objects are destroyed — not just visually covered.
5. Remove metadata on export, since author and software fields can survive independently of the page content.
6. Expect — and accept — that the redacted copy shows no valid signature. That's correct, not a defect. If the recipient needs the redacted copy signed, route it to the appropriate signer as a new document.
7. Verify the result: open the exported file, select all, copy, and paste into a plain text editor. If any redacted word appears, the redaction failed regardless of what happened to the signature.

You can do this entire workflow with SladdPDF, a free browser-based redaction tool. Files are processed locally with JavaScript and WebAssembly and are never uploaded to a server — an advantage specifically for signed documents, where routing a file through a third-party redaction service adds an extra copy of a document whose integrity already matters enough that someone bothered to sign it.