How to remove the toolchain fingerprint from a published pdf
- Step 1Read the properties of the release candidate — Open the final PDF and check File → Properties → Description before it is posted.
/Producerand/Creatortogether fingerprint your toolchain (Adobe PDF Library 17.0,Adobe InDesign 19.5 (Macintosh));/Titleoften still carries an internal codename or a draft warning. Note both dates. - Step 2Drop the release PDF onto the sanitizer — Add the file to the tool above. It routes to the canonical PDF Metadata Scrubber, which processes the document with pdf-lib in your browser. There are no options — the field set is fixed, so a comms team cannot leave a field selected by mistake.
- Step 3Run the single pass — pdf-lib loads with
ignoreEncryption: true, empties Title, Author, Subject, Keywords, Producer, and Creator, sets both dates tonew Date(0), and re-saves withupdateFieldAppearances: false. Brand layout, fonts, and imagery are untouched. - Step 4Download the clean asset and publish that copy — Save the result and post *this* file. The visible design is byte-for-byte identical; only Document Properties changed. Keep the original working file internally.
- Step 5Verify in Document Properties — Re-open File → Properties. Producer, Creator, Author, Title, Subject, and Keywords now read blank, and both dates show 1 January 1970 — the epoch — rather than vanishing. Every cleaned file shares that constant, so it reveals nothing about your real timeline or toolchain.
- Step 6Lock the published version with a hash — Record proof of the exact bytes you released. Drop the clean file on multi-hash-fingerprinter and log the SHA-256, so if a tampered copy circulates you can prove it is not the official release.
Document-info fields after stripping a release
All eight fields are handled in one pdf-lib pass. The six text fields become empty strings; the two dates reset to the Unix epoch.
| Field | What it fingerprints / leaks publicly | After sanitizing |
|---|---|---|
/Producer | Exact PDF library and version — a precise toolchain fingerprint | Empty string |
/Creator | Design app, version, and OS (Adobe InDesign 19.5 (Macintosh)) | Empty string |
/Author | The staffer who exported the file | Empty string |
/Title | Internal codename or a DO_NOT_RELEASE draft tag | Empty string |
/Subject | Classification or distribution note | Empty string |
/Keywords | Campaign tags, embargo labels, or routing codes | Empty (cleared to no keywords) |
/CreationDate | When the asset was first built | Reset to 1970-01-01T00:00:00Z (epoch) |
/ModDate | Last edit — can reveal a post-embargo change to a 'final' file | Reset to 1970-01-01T00:00:00Z (epoch) |
What stripping covers vs. what it does not
A metadata strip removes the Document-Properties fingerprint. Designer comments and the XMP packet are owned elsewhere.
| Risk in the published asset | Owned by this tool? | Tool to use |
|---|---|---|
/Producer /Creator toolchain fingerprint | Yes | This tool (pdf-metadata-scrubber) |
/Author naming a staffer | Yes | This tool |
Internal codename / draft tag in /Title | Yes | This tool |
Post-embargo edit time in /ModDate | Yes — reset to epoch | This tool |
| XMP packet still naming the app/author | No — not rewritten | Re-save via pdf-compress-lossless |
| Designer comments / review markup | No | pdf-annotation-remover |
| An embedded preview thumbnail from an earlier draft | No | hidden-thumbnail-extractor to inspect |
File-size limits by tier (PDF input)
PDF input is file-based, so Security-family tier limits apply. One file per pass.
| Tier | Max file size | Files per pass |
|---|---|---|
| Free | 10 MB | 1 |
| Pro | 100 MB | 5 (processed one at a time) |
| Pro-media | 500 MB | 50 |
| Developer | 2 GB | Unlimited |
Cookbook
Real Document Properties before and after stripping a release asset, plus the leaks a metadata pass cannot reach. Names and codenames are illustrative.
The InDesign + Adobe Library fingerprint on a white paper
/Creator and /Producer together tell any downloader the exact design suite, version, and OS your team uses — useful for competitive profiling and for crafting believable phishing against your staff. Stripping empties both.
Before (File -> Properties): Producer: Adobe PDF Library 17.0 Creator: Adobe InDesign 19.5 (Macintosh) Author: m.delacruz Title: Q2_whitepaper_DO_NOT_RELEASE Created: 2026-06-01 11:20:44 Modified: 2026-06-08 19:03:12 After sanitizing: Producer: (blank) Creator: (blank) Author: (blank) Title: (blank) Created: 1970-01-01 00:00:00 Modified: 1970-01-01 00:00:00
A 'DO_NOT_RELEASE' tag riding along in /Title
Internal working titles and embargo warnings live in /Title. Publish as-is and the public file literally announces it was a restricted draft. Stripping empties it.
Before: Title: Q2_whitepaper_DO_NOT_RELEASE Keywords: embargo, internal, board-review After: Title: (blank) Keywords: (blank) The embargo tag and routing labels are gone from Document Properties.
ModDate exposing a post-embargo edit
An embargoed release is supposed to be final at the embargo time. If /ModDate shows an edit hours after the embargo lifted, a journalist can argue the 'official' file was changed quietly. Resetting both dates to the epoch removes the evidence trail.
Before: CreationDate: D:20260601112044-07'00' ModDate: D:20260608190312-07'00' <- after embargo After: CreationDate: D:19700101000000Z ModDate: D:19700101000000Z No edit timestamp remains to scrutinize.
What stripping does NOT remove — a designer comment
Review markup left by the design team is a page annotation, not metadata, so it survives the strip — and can contain candid internal notes. Remove annotations as a separate step.
Document Properties after sanitizing: all clean. But a sticky note on page 2 still reads: "legal hasn't signed off on this number yet" This survives a metadata strip. Run /pdf-tools/pdf-annotation-remover before publishing.
Fingerprinting the official release
After stripping, hash the file so you can later prove which exact bytes were the official release if an altered copy circulates.
Workflow:
1. Strip q2-whitepaper.pdf -> q2-whitepaper.clean.pdf
2. Drop the clean file on
/security-tools/multi-hash-fingerprinter
SHA-256: e71b...9af2
3. Publish the digest alongside the download.
Readers (and you) can verify any copy against the
published SHA-256.Edge cases and what actually happens
Dates show 1970, not blank
ExpectedThe sanitizer sets CreationDate and ModDate to new Date(0) — the Unix epoch (1970-01-01T00:00:00Z), written as D:19700101000000Z. It does not delete the keys. This is by design and privacy-safe: a fixed constant shared by every released file says nothing about when the asset was built or last edited.
XMP packet still names the app or author
Not coveredInDesign and Acrobat write a rich XMP packet (dc:creator, xmp:CreatorTool, xmp:CreateDate) alongside the /Info dictionary. This tool empties /Info but does not rewrite XMP, and many viewers prefer it — so the toolchain string can survive there. Re-serialize through pdf-compress-lossless to drop the stale packet.
Designer comments and markup survive
Not coveredReview notes and sticky comments are page annotations, not metadata, so the strip leaves them in place — and they can contain candid internal remarks. Remove them with pdf-annotation-remover before the asset goes public.
Embedded preview thumbnail from an earlier draft
Not coveredDesign files and the images inside them can carry a preview thumbnail reflecting an earlier, pre-correction state. The metadata strip does not search for or remove these. Inspect for hidden previews with hidden-thumbnail-extractor before publishing visuals.
Visible page content is unchanged
Not coveredEmptying the /Info dictionary changes nothing you can read on the page. An unreleased figure, a draft watermark, or a placeholder still appears exactly as before. Metadata stripping is not a content review — proof the visible asset separately.
Encrypted / protected release file
Loaded with ignoreEncryptionThe scrubber loads with ignoreEncryption: true, so it can often open a protected file to clear metadata, but it is not a password-removal tool. If the PDF needs a password to view its pages, remove it first with pdf-remove-password on a file you own, then strip the unlocked copy.
Digital approval signature on the asset
PreservedAn approval signature covers the document's content bytes, not the /Info metadata, so stripping generally leaves it valid. The exception is a signature applied as the final incremental save over the entire byte range — re-serializing can break that coverage. Verify the signature after stripping if a valid one is required, and prefer stripping before signing.
File exceeds the tier size cap
RejectedImage-rich brand PDFs are large. Limits: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. If you are over the cap, reduce size with pdf-compress-lossless (which also re-serializes the XMP packet) or move up a tier.
Corrupt or truncated PDF fails to load
ErrorIf pdf-lib cannot parse the file — a truncated export, a broken structure, or a non-PDF renamed to .pdf — the load throws and no output is produced. Confirm the bytes are a valid PDF first with magic-byte-validator.
Frequently asked questions
Which fields does stripping clear?
Eight fields in the document-information dictionary. Six text fields are emptied to blank strings: /Title, /Author, /Subject, /Keywords, /Producer, and /Creator. The two timestamps — /CreationDate and /ModDate — are reset to the Unix epoch (1970-01-01T00:00:00Z). The same eight are processed every run; there is nothing to configure.
Why does /Producer matter for a public PDF?
/Producer (and /Creator) together name the exact PDF library, design app, version, and often the OS that built the file. Scraped across many published assets, that is a reliable fingerprint of your comms toolchain — useful to competitors profiling your operation and to attackers crafting believable phishing aimed at your staff. Emptying it is the safe state for public release.
Why do the dates show 1970 instead of being deleted?
The tool sets both date stamps to new Date(0), the Unix epoch. It is privacy-neutral by design: because every stripped file shares the same 1970 value, the dates no longer reveal when the asset was built or — crucially for embargoes — whether it was edited after the embargo time. If you need the date keys absent, this tool does not offer that.
Does the pre-publication file get uploaded anywhere?
No. Processing runs entirely in your browser via pdf-lib. An embargoed earnings release or unannounced launch PDF never leaves your machine — you are not trusting an online converter with material that is not yet public.
Will stripping change the design or layout?
No. Only the /Info dictionary entries change. Brand layout, fonts, colors, and imagery are preserved exactly — the file is re-saved, not re-rendered or re-encoded. The page count matches the input, so the published asset looks identical.
Is the XMP metadata stripped too?
No, and this matters for design files. InDesign and Acrobat write a rich XMP packet (dc:creator, xmp:CreatorTool) that this tool does not rewrite, and many viewers prefer XMP — so the toolchain string can survive there. Re-save through pdf-compress-lossless (/pdf-tools/pdf-compress-lossless) to drop the stale packet.
Are designer comments and review markup removed?
No. Comments and sticky notes are page annotations, not metadata, so they survive a strip — and they can contain candid internal remarks. Remove them separately with the PDF Annotation Remover (/pdf-tools/pdf-annotation-remover) before the asset is posted.
Could there be an old draft thumbnail hidden in the file?
Possibly. Design files and embedded images can carry a preview thumbnail reflecting an earlier state. This tool does not search for or remove those. Inspect a file with the Hidden Thumbnail Extractor (/security-tools/hidden-thumbnail-extractor) before publishing sensitive visuals.
Will stripping invalidate an approval signature?
Usually not — an approval signature covers the page content, not the /Info metadata, so it typically stays valid. The exception is a signature applied as the final incremental save over the whole byte range, where re-serializing can break coverage. Where a valid signature is required, prefer stripping before signing and verify afterwards.
How do I prove which file was the official release?
Fingerprint it. After stripping, drop the file on multi-hash-fingerprinter (/security-tools/multi-hash-fingerprinter) and publish or log the SHA-256. If a tampered copy circulates, anyone can compare its digest against the official one to see it does not match.
How big a PDF can I strip?
PDF input is file-based, so tier limits apply: Free up to 10 MB and one file; Pro up to 100 MB; Pro-media up to 500 MB; Developer up to 2 GB. Image-rich brand assets hit the caps fastest. Reduce size with pdf-compress-lossless (/pdf-tools/pdf-compress-lossless) if needed.
What is the full pre-publication checklist for a release asset?
Five steps. (1) Remove designer comments with pdf-annotation-remover (/pdf-tools/pdf-annotation-remover). (2) Strip metadata with this tool. (3) Re-serialize via pdf-compress-lossless (/pdf-tools/pdf-compress-lossless) to clear the XMP packet. (4) Inspect for a stale embedded thumbnail with hidden-thumbnail-extractor (/security-tools/hidden-thumbnail-extractor). (5) Fingerprint the final file with multi-hash-fingerprinter (/security-tools/multi-hash-fingerprinter) and publish the digest with the download.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.