In most cases, you cannot remove metadata from a PDF after it has been digitally signed without breaking the signature. A PDF signature is a cryptographic hash of the document's byte range at the moment of signing, and that range includes the Info dictionary and XMP metadata if they existed then. Editing or deleting those fields afterward changes the hash, and the signature reports as invalid. The reliable fix is stripping metadata before the document is signed, not after.
A litigation paralegal at a mid-size firm ran a batch metadata cleaner over a fully executed settlement agreement before uploading it to the court's e-filing portal — routine practice, meant to strip the drafting attorney's Windows username and an internal server file path out of the Author and Producer fields before the document became part of the public docket. Twenty minutes after filing, the clerk's office bounced the submission. The digital signature no longer validated. What looked like a five-second privacy cleanup had quietly broken the one thing that made the document legally self-authenticating.
This is not a bug in any particular tool. It is how PDF signatures are designed to work, and the same failure mode shows up constantly in law firms, HR departments, and procurement teams that treat metadata removal as a universal last step before sending a file out the door. Signed documents are the exception to that rule, and understanding why requires understanding what a signature actually locks down.
#1. What a PDF Signature Actually Signs
When a PDF is digitally signed, the signing tool does not attach a picture of a signature and call it done — that visual stamp is cosmetic. What actually happens is that the software computes a cryptographic hash (typically SHA-256) over a defined span of bytes in the file, called the ByteRange. That range covers everything in the document except a reserved placeholder where the signature value itself gets inserted. The hash is then encrypted with the signer's private key and embedded back into that placeholder, along with the signer's certificate.
Verifying the signature later means recomputing that same hash over the same byte range and checking it against the decrypted signature value. If even a single byte inside the signed range has changed — a font subset, a font kerning value, a metadata string, a trailing space — the recomputed hash will not match, and every PDF reader from Acrobat to a browser's built-in viewer will report the signature as invalid or modified.
This is the core tension. Metadata removal tools work by rewriting the document's structure: stripping the /Info dictionary, deleting or overwriting the XMP metadata stream, sometimes recompressing object streams in the process. Every one of those operations touches bytes that sit inside the range the original signature covers, which is exactly why the two operations — clean metadata, keep signature valid — are mutually exclusive once signing has already happened.
Removing a signature's visual stamp (the blue ribbon icon, the "Signed by" banner) is not the same as invalidating the underlying cryptographic signature, and the reverse is also true. A document can still show a signature graphic on the page while Acrobat reports the signature as broken underneath it — the picture doesn't know the hash failed.
#2. Where Metadata Actually Lives in the File
PDFs carry metadata in two separate places, and both are relevant here because both typically fall inside the signed byte range if they existed before signing.
| Metadata layer | What it holds | Covered by signature? |
|---|---|---|
| Info dictionary | Author, Title, Subject, Keywords, Creator, Producer, CreationDate, ModDate — the legacy, non-XML metadata block referenced by the trailer | Yes, if present pre-sign |
| XMP metadata stream | Adobe's XML-based metadata format, often duplicating Info dictionary fields plus custom schemas, rights data, and editing history | Yes, if present pre-sign |
| Object-level properties | Per-image or per-font metadata embedded in individual PDF objects, rarely user-visible | Usually, if inline |
| Metadata added after signing | Fields a viewer or workflow tool writes into a later incremental revision, outside the original signed range | Only in a later revision |
That last row is where a lot of confusion comes from. PDF supports something called an incremental update — a way of appending a new revision to a file without rewriting the bytes of the previous revision. In theory, a properly built incremental update can add new content (a second signature, a form field value, an annotation) without touching the first signature's byte range at all, which is why that first signature can remain valid even as the file grows. In practice, almost no consumer-facing metadata removal tool works this way. Standard tools open the file, rebuild its internal object structure, and save a new file from scratch — which is a full rewrite, not an incremental append, and it invalidates every signature the original file held.
#3. What Happens the Moment You Touch a Signed File
It helps to be precise about what "invalid" actually looks like, because it is not always a dramatic red banner. Depending on the reader, a broken signature can show up as:
- A red "X" or warning triangle over the signature panel in Acrobat, with a message that the document has been altered since signing
- A yellow caution icon indicating the signature is valid but the document has changed — some readers distinguish "signature cryptographically valid" from "document unchanged since signing," which is a subtler and easier-to-miss failure state
- No visible warning at all in lightweight viewers (many browser PDF viewers, mobile preview apps, and thumbnail generators don't check signature validity by default) — meaning the break can go unnoticed until someone opens the file in a tool that actually validates it, sometimes a court clerk or auditor months later
- An outright validation failure in automated e-filing or contract-management systems that reject non-conforming uploads before a human ever opens the file
That last scenario is the one that catches lawyers and compliance officers off guard most often, because the failure happens silently at the tool level, not visually in a document viewer. A file can look perfectly normal to the person who cleaned it and still fail validation the moment it reaches a system that checks.
Batch metadata tools are the highest-risk category here. If a firm runs an entire folder of executed contracts through a bulk cleaner as a matter of routine practice, every signed file in that batch loses its cryptographic validity at once, and the break is rarely caught until someone specifically checks — often well after the documents have already been distributed or filed.
#4. The Three Workflows That Actually Work
Given that constraint, there are really only three defensible approaches, and which one applies depends on whether the file is already signed.
Strip metadata before the document is signed
This is the only approach that produces a document with both clean metadata and a fully valid signature, because the fields simply don't exist when the hash is computed. Build metadata removal into the workflow as a step before the file is sent for signature, not after.
Use a proper incremental-update tool for permitted post-sign changes only
Some workflows genuinely need to add a second signature, fill a form field, or attach an annotation after the first signature exists. Tools built specifically around incremental updates can do this without breaking the earlier signature — but metadata edits are not typically among the permitted change types, so this path does not solve a metadata problem on an already-signed file.
Accept invalidation deliberately, for a labeled archival copy only
If a signed file absolutely must have metadata stripped after the fact — say, for an internal reference copy going into a document-management system — keep the original signed file untouched as the authoritative legal record, and clearly label the stripped copy as non-authoritative. Never let the stripped copy replace the original in a system that relies on signature validity.
| Approach | Signature stays valid? | Metadata actually removed? | Best use case |
|---|---|---|---|
| Strip, then sign | Yes | Yes | Any document you control before it goes out for signature |
| Incremental update (permitted changes) | Yes | No | Adding a second signature or form data — not a metadata fix |
| Post-hoc strip on original | No | Yes | Internal reference copy only, original kept as the record |
If you want to see what a signed file's metadata actually contains before deciding on an approach, inspecting it read-only with a tool like ExifTool is a safe first step — reading metadata never touches the file, only writing to it does.
# safe — read-only, does not touch the file or the signature
Author : J. Alvarez
Producer : Adobe Acrobat Pro 25.1
XMP Toolkit : Adobe XMP Core 6.0
$ exiftool -all= signed-agreement.pdf
# destructive — rewrites the file and breaks the existing signature
# only run this on a copy taken BEFORE signing, never on the executed file
Clean it before the ink dries
Free, browser-only metadata removal — run it before the document goes out for signature, not after.
#5. Certified Signatures and DocMDP: The Fine Print
The picture gets stricter still for certified signatures — the special class of signature applied via Acrobat's "Certify" workflow rather than a standard signature field. Certified signatures carry a DocMDP (Document Modification Detection and Prevention) permission level, set by the certifying party, that explicitly defines what kinds of changes are allowed afterward without breaking certification:
- Permission level 1: No changes permitted at all — any subsequent edit invalidates certification
- Permission level 2: Form filling and signing are permitted, nothing else
- Permission level 3: Form filling, signing, and commenting/annotation are permitted
Metadata modification is not part of the permitted change set at any DocMDP level defined in the PDF specification. This means a certified PDF is, if anything, less forgiving than a standard signed one — there is no configuration in which stripping metadata from a certified document leaves its certification intact. If your workflow certifies documents rather than just signing them (common in government filings and some enterprise contract platforms), the "strip before signing" rule applies with zero exceptions.
#6. How FileIntel Handles This
FileIntel's PDF Metadata Remover runs entirely in the browser — the file never leaves your device, which matters for privileged and confidential documents regardless of signature status. When the tool detects a signature dictionary in an uploaded PDF, it surfaces that upfront, before processing, rather than silently stripping fields and letting you discover the broken signature later in a validator or an e-filing portal. The goal is to make the trade-off visible at the moment it matters, not after the fact.
In practice, the workflow we recommend to legal and compliance teams is to build metadata cleanup into the document lifecycle at the drafting stage — run it on the near-final draft, confirm the Info dictionary and XMP fields are clear, and only then route the document for signature. That single reordering avoids the entire class of problem this article covers.
Treat metadata removal as a pre-signature step in your document template, not a post-execution cleanup task. If your firm uses a standard cover-sheet or drafting template, add a metadata check to the checklist immediately before the "send for signature" step — not after "fully executed" status.
Check what's hiding in your draft
Free and instant — see every metadata field before the document ever gets signed.
Frequently asked questions
Limitations
This guide covers standard PDF digital signatures as defined in the ISO 32000 specification and Adobe's signature implementation, along with the PAdES (PDF Advanced Electronic Signatures) profile common in EU compliance contexts. It does not cover password-protected or encrypted PDFs, where the interaction between encryption and signature validity introduces additional constraints. It does not address jurisdiction-specific evidentiary rules governing when a broken signature affects admissibility — that determination depends on the applicable rules of evidence and the specific court or agency involved. And it does not cover scanned, image-only "signed" PDFs that use a visual signature stamp with no underlying cryptographic signature at all — those documents have no hash to break in the first place, and their authenticity relies on entirely different mechanisms.
This article is provided for general informational purposes and does not constitute legal advice. Rules governing document admissibility, e-filing requirements, and signature validity vary by jurisdiction and by court or agency. Consult qualified counsel or your court's e-filing guidance before relying on any specific document-handling workflow for a live matter.