What PDF metadata can reveal — and what removing it does not remove

A PDF carries two separate metadata blocks, and stripping them is a narrower operation than most people assume. What is in there, and the five things that survive a clean.

Published 2 August 2026

Every PDF describes itself. Who made it, which program produced it, when it was created, when it was last saved. In most files there’s a good deal more than that, sitting in a second block almost nobody looks at.

None of it shows up when you open the document. Which is exactly why it leaks.

Two metadata systems, not one

This trips people up constantly, because a tool that cleans one and leaves the other looks like it’s done the job.

The document information dictionary is the original mechanism, in the PDF specification from the beginning. It’s a small set of named fields: Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate. This is what a viewer shows you under “Document Properties”.

XMP, the Extensible Metadata Platform standardised as ISO 16684-1, is a block of RDF/XML embedded in the file. It’s far richer, and it’s where modern software puts things. A single XMP packet routinely carries the document’s identifier, a history of edits with timestamps and tool versions, the software’s own version string, and often a duplicate of the basic fields.

The two can disagree, which is informative in itself. A Title in the dictionary that differs from the XMP title usually means the file was edited by something that updated one and not the other.

A tool that clears the Document Properties panel and leaves the XMP has removed the part you could already see and left the part you couldn’t.

What the fields actually give away

Author is the obvious one, and it’s usually the logged-in account name of whoever last saved the file. On a corporate machine that’s frequently a real name or an employee identifier.

Creator is the application the content was authored in: Word, InDesign, LaTeX, a scanner’s driver. Producer is the library that wrote the PDF bytes. Together they fingerprint a workflow, and a version string narrows it further.

CreationDate and ModDate carry a timezone offset, which is a location hint. The pair of timestamps together also reveals how long a document was worked on, and that’s occasionally the more sensitive fact. A carefully considered response created and modified four minutes apart tells a story.

Title is very often the original filename, which is where this gets awkward. Q3-redundancy-list-FINAL-v4.docx lives on as a Title long after the file itself has been renamed to something neutral.

Keywords frequently keep tags from a template or a document management system, internal project and client names included.

The pattern behind all of it: metadata records the process, and the process is usually more revealing than the document was ever meant to be.

What removing metadata doesn’t remove

This part deserves precision, because “I removed the metadata” often gets heard as “the document is now anonymous”. Those aren’t the same claim.

Visible content. A name printed on the page is part of the page. Metadata removal doesn’t touch page content at all. Removing something visible is redaction, a different operation with its own well-documented failure modes, chief among them that drawing a black rectangle over text in most editors leaves the text sitting in the file underneath.

Comments and annotations. Sticky notes, highlights and review comments are page objects, and every one of them carries the name of whoever made it. On a document that’s been through review this is often the richest source of names in the entire file, and it survives a metadata clean completely untouched.

Attachments. A PDF can embed arbitrary files. They stay embedded, with their own filenames and their own metadata.

Form field values. Anything typed into an interactive form stays, and the fields keep their internal names, which are often more descriptive than the visible labels.

Embedded fonts, images and colour profiles. Each carries its own strings. An embedded photograph can hold its own EXIF, including the camera model and sometimes GPS coordinates. Metadata inside metadata, and clearing the document’s own fields does nothing to it.

Earlier revisions. PDFs support incremental updates, so a save can append changes instead of rewriting, which leaves previous versions of pages in the file. A tool that rewrites the document from its parsed structure discards unreferenced earlier revisions as a side effect. That’s useful, but it’s a consequence of how the file gets written, not a guarantee, and it shouldn’t be relied on as one.

The orphaned-object trap

Know about this one if you’re evaluating tools, because it produces a file that looks clean and isn’t.

The XMP packet is a stream object, referenced from the document catalog. The obvious way to remove it is to delete the reference. But most PDF libraries don’t garbage-collect unreferenced objects when saving, so the packet is still sitting in the output file, just not pointed at any more. Open the result in a text editor and the XML is right there waiting.

Removing the reference isn’t removing the data. The stream contents have to be overwritten. And this is measurable: search the output bytes for a string you know was in the XMP and see whether it’s still there. Run that check on any tool you plan to trust, the one here included, whose automated tests do exactly that on every run.

Metadata isn’t always the enemy

A caveat pointing the other way, because “strip everything” isn’t automatically right.

Metadata makes documents findable, drives citation tooling, and carries accessibility information. PDF/A, the archival profile, requires XMP, so stripping it makes the file non-conformant. Tagged PDFs use structural metadata that screen readers depend on. That’s separate from the document information dictionary, but it’s a reminder that not all embedded non-visible data is disposable.

Strip metadata when you’re publishing outside your organisation, when the document has passed through many hands, or when the filename history would say more than you want it to. Keep it for archives, internal libraries, and anything where provenance is the point.

A practical routine before publishing

Look before you clean. The fields are informative. They tell you what the file has been through, and occasionally that it isn’t the file you thought it was.
Clean the document information dictionary and the XMP.
Check comments and annotations separately. They’re usually the biggest remaining source of names.
Check for attachments and form data.
Consider the visible content, which is the part metadata tools never touch.
Re-open the cleaned file and inspect it again. Verifying is cheap.

The realistic goal is to remove what you didn’t intend to send, not to make a document untraceable. Whoever receives it usually knows where it came from anyway. What you’re preventing is the accidental extra: the account name, the original filename, the four-minute edit window that nobody meant to include.

Sources and further reading

Last reviewed 2 August 2026.