PDF metadata and hidden data
Last updated:
Document metadata is the information a file carries about itself beyond the content on the page: who its fields claim wrote it, which application produced it, when it says it was created and changed, and what earlier material still sits inside it. A PDF can hold two overlapping metadata systems, a chain of earlier revisions, complete embedded files and text that renders invisibly; a JPEG photograph holds a camera diary; even a plain PNG screenshot names the software that made it. This article walks through where each of those hiding places is, why the data survives ordinary editing, and how the real-world leaks happened. To inspect a file of your own as you read, run the Document Forensics tool — it works locally in your browser — and for the reading-structure side of the same files, see your PDFs are part of your website accessibility.
Two metadata systems ride inside every PDF
The older of the two is the information dictionary, a small set of key–value pairs stored in the file’s trailer: Title, Author, Creator (the application that made the original document), Producer ( the application that made the PDF), CreationDate and ModDate. These fields are written automatically at export time, and most document authors never open the properties dialog that would show them — which is precisely why they leak. A report exported from a personal laptop carries the laptop account’s name as its author. A document started from last year’s template still names last year’s author. A “final” contract exported by an intern’s machine announces the intern. None of this is visible on the printed page, and all of it is one properties panel — or one metadata tool — away for every recipient of the file.
The newer system is XMP, an XML packet embedded in the document, built on Adobe’s Extensible Metadata Platform and described alongside the PDF specification itself, ISO 32000-2. XMP repeats much of the same ground in namespaces: dc:title for the title, pdf:Producer, xmp:CreateDate and xmp:ModifyDate, plus fields the old dictionary never had, such as the creator tool. Having two systems would be harmless if they were kept in step, but they are not: one tool updates the information dictionary and ignores XMP, another rewrites XMP and leaves the dictionary stale, a third strips one and keeps the other. The result is that a single file routinely tells two slightly different stories about itself — and the disagreement is itself information, because it records that more than one tool, at more than one moment, has had its hands on the document.
Incremental updates: the deleted paragraph that never left
PDF was designed for append-only editing. When an editor saves a change incrementally, it does not rewrite the file: it appends the changed objects, a new cross-reference section and a new trailer to the end, chaining back to the previous trailer through a /Prev pointer. Every revision ends with its own %%EOF marker, so counting those markers gives a lower bound on how many times the file has been saved this way — and every earlier revision remains physically present and readable in the bytes. Open such a file in an ordinary viewer and you see only the newest revision. Read the bytes, or roll the chain back, and the earlier state of the document is still there: the old figure in the table, the previous wording of the clause, the paragraph that was deleted before release.
This is the mechanism behind the redaction failures that keep making news. A team needs to publish a report with names or figures withheld, so someone draws black rectangles over the sensitive passages — a drawing operation that changes how the page looks and touches nothing underneath — or deletes the text in an editor that then saves incrementally, leaving the deleted objects in an earlier revision. The published file looks clean. Days later, a reader selects the “redacted” region, copies it, and pastes the original words into a text editor; or a researcher parses the revision chain and recovers what was removed. Real redaction is a different operation from covering: the underlying content has to be removed from the content stream and the file fully rewritten, so that the bytes themselves no longer contain what the page no longer shows. If a file you are about to publish carries several %%EOF markers, its history is still inside it — assume a motivated reader will read that history.
Embedded files and hidden text: the cargo nobody lists
A PDF can carry complete files inside itself. The format defines an embedded files name tree, reached through /EmbeddedFiles and /Filespec objects, and authoring tools use it for source spreadsheets, data appendices and portfolio documents. The attachment panel that would reveal them is one most readers never open, so embedded cargo travels silently: publish the polished PDF summary and you may also publish the working spreadsheet behind it, complete with its own metadata, its draft sheets and its comments. The same applies in reverse for recipients — an attachment inside a received PDF inherits the trust of the document around it, which is why embedded files deserve a line in any inspection checklist rather than discovery by accident.
Text can hide without being a separate file at all. PDF paints text with a rendering mode, and mode 3 — set with the 3 Tr operator — paints neither fill nor stroke: the characters are in the content stream, they can be selected, searched and extracted, and they are completely invisible on the page. Some invisible text is legitimate and valuable: the OCR layer behind a scanned page is exactly this, hidden text that makes an image searchable. The problem is everything else that ends up in mode 3 or its cousins — white text on a white background, text clipped off the visible page, a keyword layer added for search engines — because a reader extracting the text layer receives words the page never showed. When the hidden layer disagrees with the visible one, the file is saying two things at once, and only one of them was proofread.
Images keep diaries too: PNG chunks and JPEG Exif
A PNG file is a sequence of named chunks, and several chunk types exist purely to carry text: tEXt, its compressed sibling zTXt and the internationalised iTXt. Export tools write them habitually — a Software keyword naming the editor, a creation tool string, sometimes an entire embedded XML profile — and they survive every crop and resize that leaves the chunk list intact. The tIME chunk adds a last-modification timestamp, an eXIf chunk can carry a full camera metadata block, and bytes appended after the closing IEND chunk are ignored by every viewer while remaining in the file. A screenshot that looks like a neutral picture of a window can therefore name the machine’s software, date itself, and carry data its author never saw.
JPEG photographs go further. The file is a chain of marker segments: APP0 carries the JFIF header, APP1 carries either an Exif block or an XMP packet — sometimes both. The Exif IFD0 fields read like a camera’s diary: Make and Model of the device, the DateTime the picture was taken or last modified, the Software that processed it, and in extended directories, GPS coordinates. Phone photographs published straight from the camera roll have embarrassed organisations and individuals alike by placing them, precisely, at a time and a location the picture itself never showed. Comment (COM) segments add free text from whatever tool last saved the file, trailing bytes can sit after the end-of-image marker, and the tool that reads all of this — Phil Harvey’s ExifTool, listed in the sources — is a free download, which means your recipients can read it too.
Cross-check the timestamps, then scrub before you publish
A single timestamp is a claim; several timestamps are a story that can be checked against itself. A creation date that falls after the modification date cannot describe a document produced by one tool in one pass. An information-dictionary date that disagrees with the XMP date for the same event records two tools keeping two clocks. A date in the future records a mis-set clock, a hand-edited field, or a file assembled from pieces. Even the PDF date format invites ambiguity — the D: string may omit its timezone, leaving readers to guess which clock the numbers came from. Treat each inconsistency the way an auditor treats a ledger discrepancy: it usually has an innocent explanation — template reuse, a laptop clock, an optimiser that rewrote the file on upload — and it is evidence to weigh, never a verdict on its own. Metadata fields can be edited by anyone with free tools, so they corroborate or contradict a story; they cannot prove one.
Scrubbing is therefore a workflow, not a button. First, inspect: run the file through the Document Forensics tool and note what it would tell a stranger — author and tool names, revision count, embedded files, hidden text, timestamps that argue with each other. Second, fix at the source where you can: correct the document properties in the authoring application rather than painting over its output. Third, export a fresh, complete rewrite — printing to PDF, a dedicated scrubber, or ExifTool for images — because a full rewrite drops earlier revisions, orphaned objects and trailing data in a way incremental saving never will. Finally, re-check the copy you actually ship, not the one you meant to ship. And keep the distinction the whole article rests on: internal originals should keep their metadata, because provenance, archive value and even accessibility — a document title is metadata too — depend on it. Scrub the published copy, keep the record intact at home.