BASALT · JOURNAL

How to see everything a PDF is actually carrying

2026-08-06 · what is inside a pdf file

A PDF viewer shows you the pages. The pages are one part of the file, and often not the part that causes trouble. If you want to know what is inside a PDF file, you have to look at the object graph underneath the rendering, because the format is designed to carry material that no page displays.

The file is a graph, not a stack of pages

At the end of every PDF is a trailer pointing to a cross-reference table, and that table points to the document catalog. The catalog is the root object, and everything else hangs off it by reference.

From the catalog you reach the page tree, where visible content lives. You also reach several siblings of the page tree that have nothing to do with rendering: the names dictionary, /OCProperties for optional content, /Outlines for bookmarks, /AcroForm for form fields, /Metadata for the XMP packet, and /OpenAction for anything the document runs when it opens.

A page-by-page review walks the page tree and nothing else. That is the structural reason careful reviewers still ship documents that disclose more than they meant to.

Metadata, in two stores that can disagree

The document information dictionary holds /Author, /Title, /Subject, /Keywords, /Creator, and /Producer. /Author is usually an account name, and /Title is frequently the original filename, which carries matter names and client names more often than people expect.

Separately, /Metadata on the catalog points to an XMP packet: an XML block with its own vocabulary, typically recording a document identifier, an instance identifier linking the file to every copy derived from it, and a history of the applications that touched it.

The two stores are independent, and extraction tools read both. Clearing one is a common half-measure, and blanking a field differs from removing it.

Embedded files

The names dictionary can contain an /EmbeddedFiles name tree, and a file attachment annotation can attach a file at a point on a page. Either way, the PDF carries a complete second file inside itself.

That file is commonly the spreadsheet a chart was built from, a source document, or an email. It is not paginated, so page review never encounters it, and it is not page text, so extracting the document body will not surface it. Nothing on any page has to indicate it is there. Embedded files, the attachment inside your PDF nobody looks at covers both mechanisms.

Optional content groups

Optional content groups are the layers feature. Membership is controlled by the configuration dictionaries under /OCProperties, and a group that is off draws nothing on screen and nothing on paper.

Off does not mean absent. The operators remain in the content stream and the text extracts normally. Files from templates, CAD exports, and design tools routinely carry layers holding draft wording, internal notes, or a superseded figure, and nothing in a reading session says the document has layers at all. Hidden layers in a PDF is the longer treatment.

OCR text, annotations, and accessibility strings

A scan made searchable carries a text layer drawn in rendering mode 3: real glyphs, invisible, aligned with the picture of the words. That layer is a second, independent copy of the page, so destroying pixels without editing glyphs leaves the words fully extractable, and the reverse leaves the picture legible.

Annotation objects carry a /Contents string beside their appearance stream, and form field values live in the field dictionary rather than in the widget you see, so a field can look blank and still hold its value. /ActualText and /Alt store plain text equivalents for accessibility, which any extractor reads.

JavaScript and actions

The names dictionary can hold a /JavaScript name tree of document level scripts, /OpenAction on the catalog can fire when the file opens, and annotations and form fields can carry their own action dictionaries.

Most of this is form validation and number formatting. Occasionally it is code written against an internal system, containing hostnames or logic that describes how a firm works. Either way, you should know whether a document you are sending executes anything.

Prior revisions and stale thumbnails

PDF supports incremental updates. An edit can append new objects and a fresh cross-reference section while leaving every original byte in place, so a file edited several times can hold several earlier states of itself, reconstructable by walking backward through the cross-reference chain. Counting %%EOF markers is a quick proxy, and how to check whether a PDF was really redacted explains what to do with the count.

Pages can also carry embedded thumbnails. One generated before an edit and never regenerated is a small picture of the earlier page, usually good enough to read a name.

Doing the inspection

The command line covers most of this if you run several tools. exiftool -a -u -g1 reports both metadata stores separately. pdfdetach -list enumerates embedded files. qpdf --qdf --object-streams=disable expands the file so the object graph is readable, which matters because object streams compress many objects together and a grep of a compressed PDF finds nothing while the strings are plainly present.

The gap is that none of these produce a single inventory, and a clean result from one says nothing about the others. What you want is one report covering the whole catalog, then a decision about what to remove, rather than a guess about what might be there.