What a PDF Says About You: Reading and Clearing Its Metadata

A PDF carries its metadata twice

The first store is the Info dictionary, and it is as simple as it sounds: a small set of named entries sitting near the end of the file. Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate. That is essentially all of it, it has been there since the earliest versions of the format, and it is what almost every “document properties” panel shows you.

The second store is an XMP packet: an XML document, wrapped in RDF, embedded inside the PDF as an object of its own. It repeats most of the same ideas under different names — the title becomes dc:title, the author becomes dc:creator, the authoring program becomes xmp:CreatorTool — and it can carry a great deal that the Info dictionary has no room for: rights statements, revision histories, camera and colour data, custom fields a publishing workflow invented for itself. XMP is a specification in its own right, published separately from the PDF format and used in image and video files too.

Nothing in the format obliges the two to agree. A document written in a word processor, laid out in a design program and exported through a distiller may have picked up its Info dictionary at one step and its XMP at another. Rename the file, edit the properties in one application, save it from a second, and the two stores drift apart. This is not an exotic failure — it is the ordinary condition of a document that has passed through more than one program, which is most documents.

What the panel shows you, in both stores

The tool reads the Info dictionary and puts all eight fields in front of you as editable inputs. Below them it reads the XMP packet and lists the same eight ideas under their XMP names — dc:title, dc:creator, dc:description, dc:subject, xmp:CreatorTool, pdf:Producer, xmp:CreateDate, xmp:ModifyDate — read-only, beside the boxes they are supposed to agree with. Read-only because the packet is somebody else's XML: it is kept whole or removed whole. What the panel still keeps to itself is everything beyond those eight — rights statements, revision histories, fields a publishing workflow invented for itself. A packet carrying none of the eight says exactly that: present, with nothing this panel can line up against a field.

The test file built to make that visible had an Info dictionary calling the document a routine board pack and naming one author, and an XMP packet calling it a confidential salary review that should not be circulated, naming a completely different author and a different authoring program as well. Loading it now, the panel shows both: the routine board pack in the editable field, the salary review directly beneath it, all eight XMP rows marked as differing, and above them a line saying the two stores do not agree. The version that would have gone out unnoticed is the one now highlighted on screen.

The rest of the panel is unusually careful, and worth crediting. An empty field is removed from the file rather than written as an empty string, so a cleared title makes the document one without a title, not one whose title is blank — a distinction that matters, because readers display the two differently. A date you did not touch is left exactly as it was rather than rewritten at minute precision. And saving does not restamp the document: editing one field and saving left the Producer, the creation date and the modification date all byte-identical. Most tools that touch a PDF write their own name into the Producer field and set the modification date to now, which on a metadata tool would mean adding a fingerprint while claiming to remove one.

Clearing one store does not clear the other

Two ways of clearing were tested on the same file, and they give different results. Emptying each field by hand and saving removed the Info dictionary entries completely — every one of the eight came back empty. The XMP packet was untouched: the file still carried its XML block, still naming the confidential title, still naming the other author, still naming the other authoring program. Anyone opening the result in a tool that reads XMP would find everything the person clearing it thought they had removed. The panel now says so before you save: with the Info fields emptied, every XMP row that still carries a value is marked as differing, under a warning that saving keeps it.

The “Clear every field” button behaves differently, and better: it empties the form and ticks the “Also remove the XMP block” checkbox for you. Saving after that produced a file with no Info entries and no XMP at all — the confidential title, the second author and the distiller name were all absent from the raw bytes, not merely disconnected. That distinction matters more than it sounds: deleting only the pointer to an object leaves its bytes sitting in the file, where any parser willing to scan will find them. The removal here deletes the object itself.

The practical rule is short. Use the button, not the keyboard. Emptying the boxes yourself is the intuitive move and it is still the one that leaves half the job undone, because removing the XMP block is a separate tick that only appears when there is a block to remove. What has changed is that the tick is no longer silent: the panel marks what would survive the save and warns you. What it will not do is tick the box for you. The button does.

What the Producer field gives away

Two of the eight fields name software rather than people, and they leak more than most people expect. Creator names the program the document was written in; Producer names the program that turned it into a PDF. Both usually include a version number, and sometimes the operating system as well. The XMP packet holds both again under its own names, and nothing requires them to match: in the test file the Info dictionary named a word processor twice while the packet named a layout program and a PDF library — one document, four pieces of software on the panel.

A real published document used in these tests — a national telecoms regulator's public information sheet — names its Producer as a specific distiller release, version and platform included. That is a small thing on a public document and a rather larger one on a document you did not mean to be traced back to a particular desk. It tells a reader which software your organisation licenses, roughly when it was last upgraded, and what platform it runs on. Combine it with the creation date and you have narrowed down the machine considerably.

What survives every wipe: the document ID

Every PDF that has been saved by a serious producer carries a pair of identifiers at the very end of the file. The first is generated when the document is created and is meant never to change; the second is regenerated each time the file is updated. Together they let a program recognise that two files are versions of the same document, which is what makes incremental updates and digital signatures work.

That pair is not metadata in the sense the panel means, so it is neither shown nor offered — and it survives. A real eight-page document was taken through a complete wipe: every Info entry deleted, the XMP object removed, the file rewritten at less than half its original size. Its identifier pair came out of the other end character for character identical to the pair it went in with. If you have ever sent an earlier draft of the same document to anyone, the two files can still be matched to each other, and the identifier is stable enough to say so with confidence.

Clearing metadata is not redaction

A PDF can be edited without being rewritten. Instead of saving a new file, a program can append the changed objects to the end of the existing one, along with a small table saying which objects have been replaced. This is called an incremental update, and it is how annotations, form filling and digital signatures work without invalidating what came before. The consequence is that a PDF can contain earlier versions of its own content, still present in the bytes, simply no longer pointed at.

So the fair question is whether this tool rewrites or appends, and the answer is that it rewrites. A file was built with a page whose text was replaced by an incremental update, then put through a full metadata wipe. The output was a single-revision file at less than half the size, and a reader showed the replacement text, correctly. But the superseded original was still in there — a complete, decompressible object carrying the words the update had been meant to hide, recoverable in a few lines of code. The rebuild copies every object it knows about, referenced or not; it does not work out which ones are now unreachable.

This is not a criticism of the tool so much as a boundary around what it claims. It is a metadata tool: it removes what the file says about itself, and it does that thoroughly, in both stores, when you use the button. It is not a sanitiser, it does not garbage-collect the document, and it cannot remove text you painted a black rectangle over in some other program. If a document must be safe to publish, the metadata pass is one step of several, and the last of them should be reading the finished file back with a tool that shows you what is genuinely inside it.

Frequently asked questions

What is the difference between the Info dictionary and XMP, and why do they disagree?

They are two independent stores for overlapping information. The Info dictionary is a short list of named entries and has been part of the format since the beginning. XMP is an XML block embedded as an object, capable of holding the same fields under standard names plus anything a workflow wants to add. Nothing synchronises them. A document written in one program, laid out in a second and exported by a third can collect each store at a different moment, and renaming or re-saving updates one without the other. That is why a file can present an innocuous title in the properties panel of one reader and a quite different one in a tool that reads XMP.

The panel shows the XMP values but will not let me change them. Why?

Because a packet is a whole XML document, not eight fields. The eight on screen are the ones the Info dictionary also holds, which is what makes them comparable side by side; the same packet can carry rights statements, a revision history, colour profiles and fields a publishing workflow invented for itself, under schemas this tool knows nothing about. Rewriting the eight in place would mean re-serialising somebody else's XML and hoping nothing else in it broke — and a half-updated packet is worse than an untouched one, because it would still disagree with the Info dictionary, only less visibly. So the packet is read, compared, and then kept whole or removed whole. If you need the XMP to say something particular rather than nothing, set it in the program that produced the document.

I cleared everything. Is the document now anonymous?

Less identifiable, not anonymous. If you used the “Clear every field” button, both metadata stores are genuinely gone, which removes the author's name, the software, the versions and the dates. What remains is the document identifier pair at the end of the file, which came through a full wipe unchanged and can still link this file to any earlier copy of the same document. Beyond that, the content itself identifies you: fonts you licensed, a letterhead, a phrase you always use, a signature image, and any text an earlier revision left behind. Metadata clearing is a useful step and a poor last line of defence.

Does saving stamp the file with a new producer or a new date?

No, and that is deliberate. Most libraries that write a PDF put their own name in the Producer field and set the modification date to the moment of saving, which on a tool whose purpose is removing traces would mean adding one. Here the automatic stamping is switched off and every field is written or deleted explicitly. Tested by editing a single field and saving: the Producer, the creation date and the modification date all came back unchanged. A date you never touched is also left alone rather than rewritten — the form's inputs only have minute precision, so re-saving a date you did not edit would quietly drop its seconds, which is itself an edit.

Does clearing the metadata remove hidden or deleted content?

No. The tool removes what the file says about itself, not what the file contains. A PDF can be edited by appending changes to the end rather than rewriting it, so earlier versions of a page can still be sitting in the bytes with nothing pointing at them. This tool does rebuild the file rather than appending to it — a two-revision test file came back as one, at less than half the size, rendering the newer content correctly. But the rebuild copies every object it knows about, whether or not anything still refers to it, so the superseded original was still in the output and could be read back with a few lines of code. Treat metadata clearing as one step towards a publishable document, never as the whole of it.

Why does the tool refuse my PDF, and how should I enter keywords?

A refusal is almost always encryption. The tool says so in as many words and asks you to remove the password first. Note that a file can be encrypted without ever asking you for a password: many published documents carry a security handler with an empty user password, which lets them open instantly while still refusing to be modified. For keywords, use commas. A comma is the only separator that can be relied upon, because different producers disagree: some write keywords separated by spaces, others by commas. If your line contains no comma at all it is written exactly as you typed it, as a single keyword, rather than being split on spaces and silently turned into several.