Why are there two different metadata systems in PDF?

For historical reasons. The Document Info dictionary has existed since the format's early versions and consists of simple key-value pairs. XMP was developed in the early 2000s to answer the need for rich, extensible metadata in multimedia files, and was later added to PDF. The older system was kept for backward compatibility, so the two live side by side.

How does the XMP block sit in the file — is it compressed?

XMP is usually embedded as uncompressed, plain-text XML. The reason is to allow a file's metadata to be read without fully parsing it — search and indexing systems can scan the file and find the XMP packet. The practical consequence: if you open a PDF in a text editor, you can read the XMP content.

What does the PDF/A archival format require regarding metadata?

PDF/A makes XMP metadata mandatory and requires it to contain a specific identifier stating which PDF/A level the document conforms to. It also expects the values in the Document Info dictionary to be consistent with their XMP counterparts. That's why carelessly cleaning a PDF/A document's metadata can break its conformance.

What Is PDF Metadata? The Difference Between XMP and the Document Info Dictionary

Q: If the two systems hold different values, which one counts?

The standard recommends XMP take priority in a conflict, but implementations are inconsistent about this. Some viewers show Document Info, some read XMP, some take whichever is populated. That's why metadata cleaning has to handle both — deleting one and leaving the other means the information keeps showing up in some program.

Inside a PDF file there's a layer of information that never appears on the pages: who created it, with which program, when, and about what. That layer actually consists of not one but two different systems, and the two can conflict. This article explains the structure of PDF metadata, why two systems live side by side, and what that means for privacy.

The first layer: the Document Info dictionary

This is the simple structure that has existed since PDF's earliest versions. It's a dictionary pointed to by the /Info key in the file's trailer, containing key-value pairs:

<< /Title (Annual Activity Report)
   /Author (Jane Doe)
   /Subject (2025 fiscal year)
   /Keywords (report, financial, 2025)
   /Creator (Microsoft Word)
   /Producer (Adobe PDF Library 17.0)
   /CreationDate (D:20250312143022+03'00')
   /ModDate (D:20250315091544+03'00')
>>

What the fields mean:

| Key | Meaning | |---|---| | /Title | The document's title | | /Author | The author | | /Subject | The subject | | /Keywords | Keywords | | /Creator | The source application that created the document (Word, InDesign) | | /Producer | The library that converted it to PDF | | /CreationDate | Time of creation | | /ModDate | Time of last modification |

The distinction between /Creator and /Producer is often confused but it's logical: you wrote the document in Word (Creator), and Word's PDF engine or a plugin turned it into a PDF (Producer). The two give different information and both carry traces about you.

The date format is notable too: D:20250312143022+03'00' means 12 March 2025, 14:30:22, UTC+3 time zone. The time zone is a clue about the geography where you prepared the document.

This system's limits are clear: it has a fixed list of fields, can't carry structured data, can't hold language information, and doesn't support multiple values.

The second layer: the XMP packet

In the early 2000s, XMP (Extensible Metadata Platform) was developed for the need for rich, extensible metadata in multimedia files (photos, video, documents). It was later added to PDF as well.

XMP is an XML-based structure that sits in the file as an embedded stream:

<x:xmpmeta xmlns:x="adobe:ns:meta/">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/">
   <dc:title>
    <rdf:Alt>
     <rdf:li xml:lang="tr">Yillik Faaliyet Raporu</rdf:li>
     <rdf:li xml:lang="en">Annual Report</rdf:li>
    </rdf:Alt>
   </dc:title>
   <dc:creator>
    <rdf:Seq><rdf:li>Jane Doe</rdf:li></rdf:Seq>
   </dc:creator>
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>

What XMP brings:

Multilingual values. A title can be stored in two languages at once.
Multiple authors. More than one author can be held as an ordered list.
Extensibility. Through different namespaces, any organization can add its own fields.
Standard vocabularies. Established schemas are used, like Dublin Core (dc:), IPTC for photography, and XMP Rights for rights management.

XMP is usually embedded in the file as uncompressed plain text. That's a deliberate choice: so search and indexing systems can find and read the XMP packet without fully parsing the file. The practical consequence is that you can read the XMP content when you open a PDF in a text editor.

When the two systems conflict

Many PDFs carry both layers and the values may not match:

One program updates Document Info and doesn't touch XMP.
Another program updates XMP and leaves the old one alone.
A metadata cleaner deletes only one of them.

The standard recommends XMP take priority in a conflict. But implementations are inconsistent: some viewers show Document Info, some read XMP, some take whichever is populated.

The privacy consequence is serious. If you deleted the author name from Document Info and left it in XMP, the document properties window looks clean but your name surfaces when read with another tool. That's the most common reason behind "I thought I cleaned the metadata" stories.

A reliable cleanup has to handle both. A crude but effective verification method: open the cleaned file in a text editor (without saving) and search for strings like xmpmeta, dc:creator and dc:title.

What metadata gives away

Concrete clues:

Identity. The /Author and dc:creator fields are usually filled in automatically from your operating system username. On an anonymously submitted document that's direct identity disclosure.

Template residue. If you copied a quote from a file you prepared for a previous client, that client's name may still be in the title.

A timeline. CreationDate and ModDate show the document's real preparation process. The time zone is also a geographic clue.

A software profile. The /Producer field tells which library and version you used. That gives away information about your corporate workflow.

Corporate fields. Some corporate PDF producers add fields via custom XMP namespaces: department code, classification level, internal reference number.

PDF/A and the metadata requirement

The PDF/A format, designed for long-term archiving, brings strict rules about metadata:

XMP is mandatory. The document must carry an XMP packet.
A conformance identifier is required. The XMP has to state which PDF/A level is met, via the pdfaid:part and pdfaid:conformance fields.
Consistency is expected. The values in Document Info have to match their XMP counterparts.
Custom schemas must be defined. If non-standard XMP fields are used, their schema has to be described inside the file.

The practical consequence: carelessly cleaning a PDF/A document's metadata breaks its conformance. The file you send to an archive system fails validation. When editing metadata in PDF/A documents you need to preserve the conformance fields.

Where metadata doesn't reach

It's important to be clear about the limits of metadata cleaning, because a false sense of security is dangerous:

Page content. Metadata is information about the document; it affects nothing written on the page. If your name is on page 3, it stays there.

Hidden content. Text covered with a black box is part of the page content and isn't removed by cleaning metadata. Redaction is required.

Embedded files. PDFs can carry attachments (a source Excel sheet, appendices). Those are separate objects.

Form field data. A filled-in form's field values sit in the AcroForm structure. Flattening is required.

Version history. In a PDF using incremental updates, earlier versions can remain in the file. An operation that fully rewrites the file is needed.

Embedded fonts. Rarely, some embedded fonts carry the license holder's name in their own metadata.

The useful side of metadata

We've talked about risk so far, but metadata has real benefits too:

Corporate document management. Systems managing thousands of documents index, classify and search by metadata. Properly filled fields determine archive quality.

Web visibility. The title field appears in the browser tab and in some search results. If left empty, the file name is shown ("report_final_v3_FINAL.pdf"), which doesn't look professional.

Rights management. With the XMP Rights schema, copyright information, terms of use and contact details can be embedded into the document.

Long-term archiving. PDF/A's metadata requirement exists precisely for this: so that someone finding the file fifty years from now can tell what the document is from the file itself.

In summary

PDF metadata is a two-layer structure: the older, simple Document Info dictionary and the XML-based, rich XMP packet. The two live side by side, can conflict, and different programs read different ones — which is why privacy-motivated cleaning must handle both. Metadata carries real clues about you, from author name to time zone, and because most of it is filled in automatically it gets shared without you realizing. In exchange, properly filled metadata is a valuable asset in documents published on the web and archived; PDF/A makes it mandatory. And the limit to remember: cleaning metadata doesn't touch page content, embedded files or version history.