Every PDF carries metadata in at least two places, they frequently disagree, and most people editing a document's title are only changing one of them. Understanding the split — the old document information dictionary and the newer XMP packet — explains a range of otherwise baffling behaviour: why a title you changed still shows up in search results, why a "cleaned" file still names its author, and why archival validators reject files that look fine.
Two metadata systems
The document information dictionary is the original mechanism, present since PDF 1.0. It is a simple set of key-value pairs in the file's trailer: /Title, /Author, /Subject, /Keywords, /Creator (the authoring application), /Producer (the library that wrote the PDF), /CreationDate, /ModDate. Flat, limited, easy to read and write.
XMP — the Extensible Metadata Platform — is Adobe's XML-based metadata standard, adopted across PDF, JPEG, TIFF, and the Creative Suite formats, and standardised as ISO 16684. It is embedded in the PDF as an uncompressed XML packet, and it is far richer:
- Namespaced properties, so different vocabularies coexist without collision.
- Standard schemas: Dublin Core (
dc:title,dc:creator,dc:description), the XMP Basic schema (xmp:CreateDate,xmp:CreatorTool), Rights Management (xmpRights:WebStatement,xmpRights:Marked), Media Management (xmpMM:DocumentID,xmpMM:InstanceID). - Custom schemas, so an organisation can embed its own fields — a matter number, a records classification, a retention code.
- Language alternatives, so a title can exist in several languages.
- Structured values, arrays and nested properties.
Since PDF 2.0, XMP is the preferred location and most of the info dictionary is deprecated. In practice both are everywhere, because twenty-five years of documents and tooling do not disappear.
Why they disagree
The two systems overlap: /Title in the info dictionary and dc:title in XMP mean the same thing, and nothing enforces that they match. Common ways they diverge:
- An old tool updates only the info dictionary; the XMP retains the previous title.
- A modern tool updates only the XMP; a viewer reading the info dictionary shows the old value.
- A conversion writes fresh XMP and copies the info dictionary through unchanged.
- Someone edits properties in Acrobat, which updates both — and then a downstream script rewrites one.
The practical consequence: when cleaning metadata, you must clear both. A file whose Document Properties dialog shows an empty Author while its XMP packet still contains dc:creator with a name is a genuinely common outcome, and the XMP is what many indexing systems read. See how to strip metadata from a PDF and hidden data in PDFs explained.
Seeing what is in a file
Acrobat: File → Properties → Description shows the main fields, and Additional Metadata exposes more. The raw XMP is reachable in some versions via the metadata panel.
exiftool is the best general tool for this, and it reads both systems:
exiftool -a -G1 document.pdf
The -G1 flag groups output by source, so you can see at a glance which values come from PDF (the info dictionary) and which from XMP-dc, XMP-xmpMM and so on. When they disagree, this is how you find out.
pdfinfo document.pdf prints the info dictionary quickly. Add -meta to dump the raw XMP packet.
A text editor. XMP is stored uncompressed by design, precisely so that tools can find and read it without a PDF parser. Open a PDF in a text editor and search for <x:xmpmeta and you will see it in plain XML. That is a deliberate feature and a useful reminder that this metadata is not hidden.
What ends up in there without you noticing
Metadata accumulates. Typical unwanted contents:
- Author name from the Word or InDesign document, often a personal name on a corporate document.
- The original filename, which may reveal a client name, a version, or an internal codename.
- Creator tool and version, disclosing the software estate.
xmpMM:DocumentIDandHistory, which in Creative Suite files can record a chain of edits, previous filenames, and derivation from other documents.CreationDateandModDate, which reveal when a document was actually prepared — a recurring embarrassment when a document dated Friday was created on Monday.- Embedded image metadata, including camera details and GPS coordinates, which survives inside placed photographs.
For anything going outside the organisation, stripping this is a routine hygiene step, not a paranoid one — see sending documents securely by email and how to anonymise PDF documents.
Editing metadata deliberately
Acrobat: File → Properties → Description for the common fields, which writes both systems.
exiftool, for scripted work:
exiftool -Title="Annual Report 2026" -Author="Finance Team" report.pdf
exiftool -XMP-dc:Title="Annual Report 2026" report.pdf
exiftool -all:all= cleaned.pdf # strip everything
Note that exiftool writes an _original backup by default; add -overwrite_original when scripting, deliberately.
pdftk: dump_data and update_info handle the info dictionary; dump_data_utf8 for non-ASCII. XMP requires update_info_utf8 with an XMP file in newer builds, or another tool.
Ghostscript rewrites metadata during processing, which is worth knowing because it means running a file through Ghostscript for another reason will change its /Producer and possibly discard XMP you cared about.
PyMuPDF: doc.set_metadata({...}) for the info dictionary and doc.set_xml_metadata(xml) for XMP — the cleanest programmatic route when you need both.
Where metadata earns its keep
It is easy to treat metadata as a liability to be stripped. It is also genuinely useful:
Findability. A document management system indexes title, author, subject and keywords. A folder of files with empty metadata is searchable only by filename and full text. See document management systems explained and how to organise digital documents.
Records management. Custom XMP schemas can carry a records classification, a retention code, a matter number, or a security marking that travels with the file rather than living in a database that may not follow it. This is how serious archives handle classification — see document retention policies.
Rights. xmpRights fields state the licence, the owner and the usage terms in a machine-readable way. Photographers and publishers rely on this; most business documents ignore it.
Provenance. xmpMM:DocumentID and DerivedFrom let you trace a rendition back to its master, which is exactly what a preservation system needs. Relevant to the OAIS model for document preservation.
Accessibility and archival compliance. PDF/A requires XMP metadata, including the pdfaid:part and pdfaid:conformance identifiers that declare which flavour the file claims. A PDF/A file with no XMP is not a PDF/A file, which is why validators reject documents that otherwise look correct. PDF/UA similarly requires an identifier plus a /Title that is actually set and displayed.
Practical policy
For an organisation producing documents at any volume, three rules cover most of it:
- Set the title properly on every published document, and configure viewers to display it rather than the filename (how to set the initial view of a PDF covers the setting). It costs nothing and improves search results, browser tabs, and accessibility all at once.
- Use an organisational identity rather than a personal one in the Author field for corporate documents, unless the individual attribution is intended.
- Strip metadata on the way out, as a step in the publication process rather than a thing people remember to do. Automating it with
exiftoolin whatever pipeline produces your public files takes an hour and removes an entire recurring class of disclosure.
Summary
PDFs carry metadata twice — in the legacy info dictionary and in an XMP packet — and the two routinely disagree, which is why a cleaned document can still name its author. Read both with exiftool -a -G1, clear both when sanitising, and set the title deliberately on anything you publish. XMP is also where archival and accessibility conformance is declared, so for PDF/A and PDF/UA it is not optional metadata but part of what makes the file valid.
