What Metadata Do Public PDFs Carry? A Study of 2009-Era US Government Documents

We read 4,641 PDFs from a fixed sample of 2009-era US government documents and counted what each one carried besides its pages. 99% had at least one text field filled in (title, author, subject, keywords, creating software), 65.7% named an author, and 7.9% had a file path, an e-mail address or a network path inside one of those fields. This describes this sample. It is not a claim about PDFs made today.

We then ran HerePDF's own Metadata and Remove Hidden Data tools over the same files, with every option switched on, and searched the results for what was supposed to be gone. The study found two gaps in our own tool; both are fixed, and the section below says what they were.

How the sample was chosen

GovDocs1 is a public research collection of about a million web documents published by US federal agencies, gathered in 2009 and split into 1,000 numbered zip files of random documents each. We took 20 of them, every 50th (000, 050, 100 and so on up to 950). The rule was fixed before we looked at a single result, and the SHA-256 checksum of each zip is in the data file published with this study, so anyone can check they are using the same files.

The 20 zips held 19,693 files, of which 4,840 were PDFs; the rest were other kinds of document and were not looked at. Of the PDFs, 4,641 could be analysed. 199 could not: 197 were password-protected and 2 failed to load (parse-error). Every percentage below is out of the 4,641 that were analysed.

What was measured

Each file was read with HerePDF's own code, so the figures are what its tools would show you. For each file only yes-or-no answers, counts and categories were kept. A name or a path was read to decide a flag and then discarded: none appears in this page or in the published data. To check the reading itself, 200 files chosen by a fixed rule were read again with a different PDF reader (PDF.js), and the two agreed on 199 of 200. We read each of the 1 difference by hand: 1 was a file with a real XMP block that PDF.js did not parse.

The document properties

Every PDF can carry a small set of properties: title, author, subject, keywords, the program that made the content and the program that wrote the file, and two dates.

A second copy: XMP

Many files carry a second, separate block of the same kind of data (XMP). It can disagree with the first: someone clears the Author in one place and not the other.

Text that looks like paths and addresses

A title or creator field often holds whatever the program put there. We counted files where one of the fields contained text that looks like a local file path, an e-mail address or a network path. We did not record what any of them said.

Edit history and what else was inside

The programs behind the files

Counting by the family of program named in the Creator and Producer fields:

What HerePDF's tools left behind

For each of the 4,641 files that loaded, the Metadata tool ran with every property cleared, the XMP block removed and photo data stripped. Remove Hidden Data then ran on its output with every category switched on. We opened the results as a determined reader would, loading every object, including any the file no longer uses. The check is structural, so a title that is also written on a page, or a bookmark with the same words, does not count.

We looked for: an XMP block, camera data in embedded photos, attached files, scripts, comments and markup, and copies of the document properties anywhere in the file. We did not scan for page thumbnails and program-private data, or for the form answers the run also cleared, so the results say nothing about those. The test ran on the same 4,641 files as the tables above. 199 PDFs were left out of the test: 197 are password-protected and the rest could not be read at all.

After both tools, 4,639 of 4,641 files had none of the items listed below left, and no tool run lost a page. In the other 2, this was left:

After the Metadata tool alone, before Remove Hidden Data ran:

The study found five real gaps in our own tools, and we fixed all five. First, PDFs made in Acrobat by combining or converting files can keep each source document's title, author and creating software in the page structure or in lists attached to the page content. After the Metadata tool alone, 27 files still had such a copy in the page structure and 3 in a content list; Remove Hidden Data cleared the document's own properties and left them, and now removes them too. Second, a calculation or format script on a form field that groups several boxes was not found: 2 files kept one. Third, a form field with no type entry, which the PDF standard requires but some programs leave out, made Remove Hidden Data refuse to open the file at all: 2 files. Fourth, the Metadata tool's photo step could not see inside a photo stored with a second compression layer around the JPEG, so it left that photo's camera data in: 2 files had camera data only in such photos. It now unwraps them, strips them and stores them as a plain JPEG. Fifth, the Metadata tool unlinked the XMP block under the standard Metadata key but not one that a program had hung off a key spelled MetaData with a capital D, or off a structure element, a name tree or an array: 10 files kept one. It now finds a block by what it contains and unlinks it wherever it is held. The Metadata tool edits only the document's own properties, so the first kind remains after it alone, as the second table shows.

What is left after both tools is an XMP block inside an embedded EPS file, in 2 files. Neither tool opens an embedded file, so neither touches the block. A limit of the check: it looks for the items listed above, so a name or a path written on the page itself, or in a picture, would not be found. See checking a PDF before you send it for what each tool leaves, and how we test for the method.

What this does not show

• It is documents published by US federal agencies in 2009. Other sources, other years and other kinds of PDF can look quite different.
• These are files their owners chose to publish on the web. Files shared privately may carry more.
• A field being filled in does not mean it names a person. The study counts fields, not people, and says nothing about the risk to anyone.
• Programs have changed. The share of files made by each family of software in 2009 is not today's.
• Password-protected files were not read, and the percentages leave them out.

Repeat it

The sample rule, the SHA-256 checksum of each zip and every count are in the data file that goes with this study. The files are in the Digital Corpora archive under corpora/files/govdocs1/zipfiles, numbered 000 to 999. Take the same 20 zips, keep the files that start with %PDF-, and count the same things. For your own PDFs the quickest check is the Metadata tool, and the older guide on what PDF metadata reveals explains what each field means.

Everything on HerePDF runs in your browser. Your files are not uploaded, before or after you use these tools.