Four Famous Leaks.
What Their Bytes Still Admit.
We read four well-known leaked PDFs two different ways. The first is what any PDF reader, or ExifTool, or most sanitizers show you. The second is what is physically in the bytes. Sometimes those views agree. Sometimes the gap between them is the story.
A PDF has two layers of metadata. The one a PDF reader shows you, the one ExifTool reports, the one File X-Ray surfaces by default, is the document-level metadata. It lives in one specific place (the Info dictionary, or the XMP block at a specific spot in the file) and you reach it by following the PDF's cross-reference table. Every well-behaved PDF tool reads it the same way.
Underneath that is the raw file. Every byte that has ever been written into the PDF, including stuff the cross-reference table now points away from (because the file was edited) and stuff that sits inside embedded images and embedded XObjects (which have their own XMP). No normal reader shows you this layer. A hex editor does. So does any parser that ignores the cross-reference table and just scans bytes.
For this post we read four famous leaked documents both ways. We ran ExifTool (the reference metadata tool, used by most of the industry) and compared its output against a raw-byte scan that does not trust the cross-reference table. The disagreements are what this post is about.
ExifTool says this file is clean
On June 5, 2017, The Intercept published a classified NSA report describing Russian military attempts to spearphish US election officials before the 2016 vote. Two days earlier, an NSA contractor named Reality Winner had been arrested for leaking it. The version that now sits on Wikimedia Commons is the file we scanned.
When you run ExifTool against this PDF, the only metadata it reports is a creation date and a modification date. Both say 2017:06:05 12:17:15. No title, no author, no producer. It looks sanitized.
Apache Tika, which powers the metadata extraction pipelines at many Fortune-500-scale content systems, also reports the file as clean. Both tools follow the PDF spec's cross-reference table, and this file's cross-reference table points at a set of dates and nothing else.
Except a raw byte scan of the exact same file finds two fields sitting at byte offset 5,800,554 that neither tool reported:
"GRU" is the Russian military intelligence agency. "Final" implies drafts. That is the working filename of the redacted version someone at The Intercept prepared for publication, preserved in UTF-16 inside the Title field. The Producer field is a Homebrew Cellar path, which tells you the file was processed by ImageMagick 6.9.7-0 on a Mac.
So why does ExifTool miss these? Because the file carries a signature that the raw scan catches and ExifTool steps over:
Somebody ran ExifTool on this PDF with the intent to remove the Title and the Producer. When ExifTool modifies a PDF, it does not rewrite the file. It appends an incremental update to the end: a new object with the fields blanked out, plus a new cross-reference table that points to the blanked version. The original object, with GRU-final and the ImageMagick path, is never removed. It just stops being the object the cross-reference table points to.
When ExifTool later reads the file, it follows its own update and reports "clean." Apache Tika does the same. Every well-behaved PDF tool does the same, because that is literally what the spec tells them to do. The bytes are still there for anyone who ignores the cross-reference table: grep, a hex editor, any forensic parser, File X-Ray.
This is the most uncomfortable finding in the post. Any PDF that has been "cleaned" with ExifTool still contains its original metadata at the byte level, and no flag changes that: -overwrite_original only decides whether the .pdf_original backup is kept, and produces a byte-identical result. Removing the old values means rewriting the file with something else. That is a lot of supposedly redacted documents in the wild.
Jack Smith, named in the Author field
The federal indictment that charged Donald Trump with 37 counts over classified documents at Mar-a-Lago was filed in the Southern District of Florida and posted to justice.gov on June 9, 2023. Both readings of the file return the same values. No scrub, no embedded weirdness, one generation of bytes. Which makes the metadata read like an office intake sheet.
The Author field of a federal indictment reads Special Counsel Jack Smith. His full name, typed into the metadata of his own filing. It is not a leak or a mistake, it is a choice nobody ever scrubs. Court filings usually hide behind an office. The XMP broadcasts the person.
Paper Capture Plug-in is Adobe Acrobat's built-in OCR tool. It names itself in the Producer field only when the PDF was produced by scanning and running OCR on physical paper. The DOJ had a clean digital source somewhere. They printed it, scanned the printout, OCR'd the scan, and published the result. The file has no native text layer, just OCR'd images. This is the standard DOJ workflow for publishing filings.
The timeline on the day is visible, too. Created at 1:08 PM Eastern, last modified 69 minutes later at 2:17 PM, then posted publicly.
The Mueller Report's production schedule
The Mueller Report is the most-downloaded legal document of the last decade. Its document-level metadata is rich but unsurprising: a 448-page PDF produced with Adobe Acrobat Pro DC 19.12.20036, authored by the "Special Counsel's Office," with a Keywords field that reads like a search engine optimization attempt.
The Keywords field literally names Robert S. Mueller, which is a strange choice for a document that was already public, unless you imagine someone inside the DOJ wanting to make sure it would rank well in the department's internal document library.
Two annotator identifiers sit inside the file: EES and elb. These are initials written into annotation author fields, which PDF readers preserve when someone reviews a document in Acrobat. Two people touched this file during review. Neither is named in any public source we could find.
The byte-level scan also shows the production schedule in unusual detail. There are three separate XMP blocks in the file, not the one you see at the document level. The first sits at byte 8,142,274 and names its producer as Adobe Acrobat Pro DC 19 Paper Capture Plug-in - the OCR tool again, but here tagged onto an individual page image, timestamped 2019-08-26. The document-level XMP dates the final export three days later, on 2019-08-29, and records two more modification stamps on 2019-09-03: one at 12:57 PM, another 25 minutes later at 1:22 PM. The bytes tell you when the scans happened, when the export happened, when the last two saves happened. Each one is a separate save event inside the file.
The Jan 6 report's document-level metadata is blank. Its images aren't.
The final report of the House Select Committee on January 6 is 95 megabytes across 845 pages. At the document level, its metadata is almost empty. No title, no author, no subject, no keywords. Just a creator tool name (XPP, a specialist typesetting platform used by the Government Publishing Office for congressional documents), a producer (PDFlib 9.2.0 on Windows), and timestamps. It was published on GovInfo on December 22, 2022, after three distinct save events the bytes remember perfectly.
But the report contains photos, and the photos carry their own metadata.
Franmarie Metzler was the official photographer for the US House of Representatives from 2009 to 2021. Two of the photos in the January 6 report came from the House photo archive, and when they were embedded into the PDF the PDF generator preserved their entire XMP block. So the report now contains her name, her Lightroom version (7.3.1 on macOS), the name of her internal Lightroom collection (My Approved Portraits), and the exact timestamps when she processed those images at her desk between December 2018 and January 2019. None of this was visible at the document level. All of it is in the bytes.
The file's production pipeline is visible the same way. There are 84 separate XMP blocks scattered through the bytes. Most are image placeholders. Six name Adobe Illustrator 26.4 as the creator of embedded graphics. Three XMP blocks sit near the end of the file and show the document's save schedule: 2022-12-28 17:08, 2022-12-29 08:04, and 2022-12-29 16:13:59. The last timestamp is the minute the Government Publishing Office's digital signature was applied.
That signature is worth naming. The report carries a GPO form field whose stated reason reads, verbatim, Government Publishing Office attests that this document has not been altered since it was disseminated by Government Publishing Office. It's the closest thing to a cryptographic receipt of authenticity in any of the four files we scanned. And it coexists with Franmarie Metzler's Lightroom collection name in the same document.
What these four files have in common
ExifTool's scrub is not a scrub. By default it appends an incremental update instead of rewriting the file. The file grows; the old bytes stay. Every PDF "cleaned" with exiftool -Title= -Author= file.pdf still contains the original values at the byte level, whatever flags are added. This is documented behavior, not a bug, and it is worth knowing if you have ever sent a PDF to a reporter, a lawyer, or an external vendor expecting the fields to actually be gone.
Document-level metadata only shows part of the file. Every tool we know of (ExifTool, PDF readers, our production parser until this week) reads a single metadata block per file. PDFs can contain dozens or hundreds more, inside embedded images, form XObjects, and previous generations of the file. The Jan 6 report holds Franmarie Metzler's portrait metadata in this layer. The Mueller Report holds an OCR trail. Both are invisible to any tool that only reads the document-level block.
The DOJ prints, then scans. Both the Mueller Report and the Trump Florida indictment list Adobe's Paper Capture Plug-in as a producer somewhere in the file. Different administrations, different Special Counsels, same pipeline. The original Word documents exist somewhere internally, but the public release is always scan-of-a-printout. Text search in the published PDFs is correspondingly shaky.
Names leak at the individual level. A federal indictment names Jack Smith in its Author field. An 800-page congressional report names a House photographer via embedded Lightroom exports. An NSA leak's publisher typed GRU-final into their working filename and it rode into the PDF. In every case, the person who handled the file at each stage left their signature in a field nobody expected a reader to care about.
Reproduce any of this
Every claim above is reproducible. Download the files from the URLs below, confirm the SHA-256, and drop each into filexray.orygn.tech/scan. You will see the document-level metadata and, where applicable, the byte-level residue flagged alongside it. For the ExifTool view, run exiftool -a -G1 -s file.pdf and compare.
Check your own files
File X-Ray reads PDFs the same way we just read these four. It surfaces the document-level metadata a normal PDF reader shows, plus the byte-level residue that sits underneath: orphaned fields from incremental updates, metadata preserved inside embedded images and graphics, and an explicit warning when a file carries an %BeginExifToolUpdate marker. The whole pipeline runs in the browser and the PDF is never uploaded.
Useful before sending a draft to an external party. Useful when a file shows up in your inbox and you want to know where it came from. Especially useful if you have cleaned a PDF with ExifTool and want to confirm the scrub actually stuck.