How to remove software application info from a pdf's metadata
- Step 1See your current fingerprint — Open the PDF in Acrobat (File → Properties → Description) and read the Application (Creator) and PDF Producer lines, or run
exiftool file.pdfand noteCreator,Producer, andCreator Tool. That trio is what you are removing. - Step 2Drop the PDF onto the scrubber — Add the file above. It loads locally with pdf-lib — bytes are read in your browser and never uploaded.
- Step 3Let it run automatically — The scrubber is a no-options tool, so it runs as soon as the file is added. There is no Creator/Producer-only checkbox — both fields are emptied along with the rest in a single pass.
- Step 4Download the scrubbed PDF — Save the cleaned copy. Producer and Creator in the document-info dictionary are now empty and were not re-stamped on save.
- Step 5Drop the XMP CreatorTool for a strict check — Because this tool leaves the XMP packet alone, re-save through pdf-compress-lossless to rebuild the document and remove the residual
xmp:CreatorToolstring, then re-verify. - Step 6Verify with ExifTool — Run
exiftool scrubbed.pdf | grep -iE 'creator|producer'. The info-dictionary lines should be blank. If aCreator Tool(XMP) line persists, that is the XMP residual the lossless re-save removes.
Software fingerprint fields and how this tool treats them
The classic info-dictionary fields are emptied in one pass. The XMP equivalent is not rewritten by this tool.
| Field | Example value | After this tool |
|---|---|---|
/Creator (info dict) | Microsoft Word / Adobe InDesign 19.0 | Empty |
/Producer (info dict) | Adobe PDF Library 24.1 / Skia/PDF m124 | Empty (and not re-stamped on save) |
xmp:CreatorTool (XMP packet) | Adobe InDesign 19.0 (Macintosh) | Unchanged — re-save losslessly to drop it |
pdf:Producer (XMP packet) | Adobe PDF Library 24.1 | Unchanged — XMP not rewritten |
/Author, /Title, /Subject, /Keywords | Various | Emptied in the same pass |
/CreationDate, /ModDate | Real timestamps | Reset to 1970-01-01T00:00:00Z |
Common Producer / Creator strings by source app
What you typically find before scrubbing, so you know exactly what is being removed. Versions illustrate the patch-level detail these fields can leak.
| Source | Typical Creator | Typical Producer |
|---|---|---|
| Microsoft Word + Acrobat | Microsoft Word | Acrobat PDFMaker 24 for Word / Adobe PDF Library 24.1 |
| Word 'Save as PDF' | Microsoft Word | Microsoft: Print To PDF |
| Adobe InDesign export | Adobe InDesign 19.0 | Adobe PDF Library 19.x |
| LibreOffice Writer | LibreOffice 7.6 | LibreOffice 7.6 |
| Chrome / Chromium print to PDF | (often empty) | Skia/PDF m124 |
| Server-side generator (iText/PDFBox) | (varies) | iText 7.2.5 / Apache PDFBox 3.0.1 |
Cookbook
Before/after fingerprint snapshots as read in Acrobat and ExifTool. The info-dictionary lines go blank; watch the XMP CreatorTool line for the residual.
Hiding the Word + Acrobat toolchain
A document exported via Acrobat PDFMaker leaks both the Office app and the exact Acrobat/library version. The scrubber empties both.
Before (Acrobat → Description): Application: Microsoft Word PDF Producer: Acrobat PDFMaker 24 for Word (Producer 2): Adobe PDF Library 24.1 After scrubbing: Application: (empty) PDF Producer: (empty)
InDesign version leaked through Creator
A design studio's InDesign version is a competitive tell and a CVE map. After scrubbing, the info-dictionary Creator is gone; the XMP CreatorTool still names InDesign until you re-save losslessly.
Before: Creator (info): Adobe InDesign 19.0 XMP CreatorTool: Adobe InDesign 19.0 (Macintosh) After metadata-scrubber: Creator (info): (empty) ✓ XMP CreatorTool: Adobe InDesign 19.0 (Macintosh) ✗ still there Then re-save via pdf-compress-lossless -> XMP dropped.
Confirming Producer is not re-stamped
A common worry: does the tool stamp its own Producer back in on save? No — it loads with updateMetadata:false and sets Producer empty, so the output stays clean.
Implementation detail:
load(buffer, { updateMetadata: false }) // don't auto-touch
doc.setProducer("") // force empty
doc.save(...) // no re-stamp
Result: Producer field is empty in the downloaded file.Chromium print-to-PDF fingerprint
Files printed from Chrome carry a 'Skia/PDF m124' Producer that pins the browser build. Scrubbing removes it from the info dictionary.
Before: Producer: Skia/PDF m124 After: Producer: (empty) (If generated server-side via headless Chrome, also re-save losslessly to clear any XMP pdf:Producer.)
ExifTool audit of the final file
One command surfaces both the info-dictionary and XMP software fields so you can confirm the fingerprint is gone.
$ exiftool -G1 -s final.pdf | grep -iE 'creator|producer' [PDF] Creator: (blank) [PDF] Producer: (blank) [XMP-x] CreatorTool: (no line after lossless re-save)
Edge cases and what actually happens
XMP CreatorTool still names the app
XMP not rewrittenThe tool empties the info-dictionary Creator/Producer but does not touch the XMP packet, which carries the same software string in xmp:CreatorTool and pdf:Producer. Tools like ExifTool read these. Re-save through pdf-compress-lossless to rebuild the document without the residual XMP.
Worry that pdf-lib re-stamps its own Producer
Preventedpdf-lib can write its own Producer on save, but this tool loads with updateMetadata: false and explicitly sets Producer to empty before saving, so the output is not re-stamped. The downloaded file's Producer stays blank.
Forensic fingerprint in the content stream
May persistBeyond named fields, some generators leave subtle, non-standard markers in the content stream, object ordering, or font subset naming that a deep forensic analysis can fingerprint. A metadata scrub does not normalise these. Re-saving through pdf-compress-lossless rebuilds the structure and reduces (but cannot guarantee elimination of) such tells.
PDF/A requires Creator metadata
Conflicts with PDF/APDF/A archival profiles require consistent metadata, including a Creator/CreatorTool. Scrubbing those fields makes the file non-conformant. Scrub only distribution copies; keep an unscrubbed PDF/A master if you need archival conformance.
Producer was already empty
ExpectedIf the source had no Producer/Creator (e.g. some Chromium prints leave Creator blank), the tool writes empty values — a no-op for those fields — and still resets the dates and clears the others.
Signed document re-saved
Signature breaksRemoving the software fields re-saves the file and invalidates any existing signature, whose own metadata may also reference the signing application. Scrub before signing; verify with pdf-signature-verify.
File over the free 2 MB / 50-page limit
BlockedFree handles 2 MB and 50 pages; Pro raises this to 50 MB and 500 pages. The tool checks size and page count on load and blocks before processing if you exceed your tier.
Multiple files at once
Not supportedThe metadata scrubber is a single-file tool (it does not accept multiple files). To strip the fingerprint from a batch, process them one at a time, or pair the @jadapps/runner and POST each file to the local endpoint.
Frequently asked questions
Which software fields does the tool remove?
It empties the document-information /Creator (authoring app, e.g. 'Microsoft Word') and /Producer (PDF engine + version, e.g. 'Adobe PDF Library 24.1'). It does not rewrite the XMP xmp:CreatorTool / pdf:Producer fields — those need a lossless re-save to remove.
Will the tool stamp its own software name in on save?
No. It loads with updateMetadata: false and explicitly sets Producer to empty before saving, so pdf-lib does not write its own Producer string back in. The downloaded file's Producer and Creator stay blank.
Can a competitor still tell which software I used?
After scrubbing plus a lossless re-save (to drop XMP), the named fields are gone. But a determined forensic analysis can sometimes fingerprint a generator from content-stream quirks, object ordering, or font subset names — things no metadata tool normalises completely. For most threat models, the named-field removal is sufficient.
Does the XMP stream also contain the software name?
Yes — xmp:CreatorTool usually carries the authoring app and pdf:Producer the library. This tool does not rewrite XMP. Finish by re-saving through pdf-compress-lossless, then confirm with exiftool -CreatorTool file.pdf.
Why do security teams care about the Producer field?
The Producer string often includes an exact version, which can map to a known CVE in that PDF library, and it pins your toolchain across documents that should look unrelated. Removing it shrinks both the attack-surface intel and the correlation signal.
Will scrubbing affect PDF/A compliance?
Yes — PDF/A requires Creator/CreatorTool metadata to be present and consistent, so a scrubbed file is no longer conformant. Scrub only distribution copies and keep an unscrubbed PDF/A master if you need to archive.
Does removing software info change how the PDF looks?
No. These are hidden metadata fields. The pages, fonts, and layout are unchanged; only Document Properties is affected.
Is the file uploaded anywhere?
No. The scrub runs in your browser with pdf-lib. The document and its toolchain markers never leave your device; only an anonymous run counter is recorded for signed-in users.
Can I keep the software info but remove only the author?
No — the tool clears all document-info fields together, including Creator and Producer. There is no selective mode; if you need to keep a field you'd re-set it afterwards in a PDF editor.
What's the largest file I can scrub?
Free: 2 MB / 50 pages. Pro: 50 MB / 500 pages. Pro+Media: 500 MB / 2,000 pages. The operation only rewrites metadata, so runtime is dominated by loading the file.
Can I batch-strip software info from many PDFs?
This tool is single-file in the browser. For a batch, pair the @jadapps/runner and POST each file to 127.0.0.1:9789/v1/tools/pdf-metadata-scrubber/run. The tool takes no options, and processing happens locally on your machine.
Will scrubbing break a digital signature?
Yes — any re-save invalidates an existing signature, and the signature's own metadata may reference the signing app. Scrub before signing; check signatures with pdf-signature-verify.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.