Your PDFs Are Leaking Metadata (and Nobody Checks Before Sending)

A vendor once sent me a polished proposal PDF. The document info told a different story than the cover page: the author field carried an employee's full name, the title was an internal codename with a client's name in it, and the creator string named a tool chain they would probably not have chosen to advertise. None of it was secret, exactly. All of it was information they never decided to share — it just rode along in the file.

PDFs accumulate metadata at every step: the authoring app writes a title, author, and creator; generators add producer strings and timestamps; some pipelines embed custom fields with internal IDs. When a file leaves your machine, all of that goes with it. Cleaning it is a two-minute job, but only if you look first.

What is actually in there

The standard fields are Title, Author, Subject, Keywords, Creator, and Producer, plus creation and modification timestamps. Any PDF reader shows them under document properties — no special tooling required. The leaks that matter in practice:

• Names. Author fields with personal names on documents meant to be anonymous (blind reviews, RFP responses, anything submitted for neutral evaluation).
• Internal vocabulary. Draft titles, codenames, ticket IDs, and client names from an earlier use of the file as a template.
• Timestamps that contradict the story. A "final" report whose modification date is twenty minutes after the version you sent last week is fine. One whose creation date predates the data it claims to present gets questions.
• Toolchain fingerprints. Creator and Producer strings announce exactly which software made the file — occasionally useful information for someone probing what to exploit, always free information you did not mean to give.

The cleaning pass

Before a document goes outside, I run it through a metadata removal tool — PDFLean's is the one in my routine; the feature exists in most serious PDF toolkits, and exiftool -all= file.pdf does it locally if you prefer the command line. The pass is mechanical:

1. Open the properties of the outgoing file and actually read the fields. Cleaning without looking means you will never learn what your pipeline writes by default.
2. Strip everything, or set the fields deliberately: a proper title and your company name as author is often better than a suspicious blank, because a blank says "scrubbed" while a title says "published."
3. Re-open the cleaned file and confirm the fields are what you intended — and that the document itself is untouched: same pages, same text, same size class. Metadata removal should never alter content; if the page count changed, you used the wrong tool or the wrong mode.

Fix it at the source, too

If your generator writes bad metadata by default — and most do, usually the developer's name or a framework string — the durable fix is one configuration change in the generation step, not a lifetime of manual scrubbing. Set the title from the document's real title, the author to the organization, and let the pipeline produce clean files from birth. The manual pass then becomes a spot-check for the files that arrive from elsewhere: vendor documents you forward, scans from other people's tools, anything whose provenance you did not control.

Metadata is the least glamorous part of a PDF. That is exactly why it leaks: nobody's checklist has a line for it. Add the line. Two minutes of looking beats explaining to a client why their codename was in the file you sent them.