Portable Document Format

Object-Based Structure

A PDF file has four sections: header, body, cross-reference table, and trailer. The header declares the PDF version (%PDF-1.7 or %PDF-2.0). The body contains numbered indirect objects — dictionaries, streams, arrays, strings, names, numbers, and booleans. The cross-reference (xref) table lists every object number with its byte offset from the file's start. The trailer points back to the xref table and identifies the root object (the document catalog).

Objects reference each other by number. The document catalog points to a page tree. The page tree contains page objects. Page objects reference content streams, font dictionaries, image XObjects, and other resources. This graph structure means a PDF reader can resolve any reference by looking up the object number in the xref table and seeking directly to that byte position.

Content Streams and the Graphics Model

PDF pages are rendered by executing a content stream — a sequence of operators that manipulate a graphics state machine. Text operators like BT, Tf (set font), Tm (set text matrix), and Tj (show string) place glyphs. Path operators like m (moveto), l (lineto), re (rectangle), and f (fill) draw shapes. The cm operator modifies the current transformation matrix for scaling, rotation, and translation.

This operator model means PDF is not reflowable. Each glyph has an absolute position. Extracting running text from a PDF requires reconstructing reading order from scattered coordinates — a task that fails silently when documents use complex layouts, right-to-left text, or decorative positioning.

Font Embedding

PDF supports three font embedding strategies. Full embedding includes every glyph in the font program. Subset embedding includes only the glyphs used in the document, prefixed with a six-letter tag (e.g., ABCDEF+Helvetica). CIDFont embedding handles CJK fonts with thousands of glyphs using a character identifier mapping.

Subsetting reduces file size dramatically — a 2 MB OpenType font becomes a 30 KB subset for a typical business letter. The tradeoff: subsetting breaks text extraction if the encoding mapping is incomplete or uses custom glyph names. Some PDF generators write ToUnicode CMaps to resolve this. Others do not, producing files where copied text becomes garbled.

Incremental Updates

PDF supports incremental saving. Instead of rewriting the entire file, a PDF editor appends new or modified objects, a new xref table, and a new trailer to the end of the file. The previous content remains intact. This makes saves fast — editing one annotation in a 200 MB file appends only a few kilobytes. Multiple save cycles stack: a file edited ten times contains ten appended revisions.

The cost is bloat. Each revision duplicates modified objects without removing the originals. A 5 MB file can grow to 15 MB after heavy editing. Removing this bloat requires a full rewrite, which some tools call "Save As" or "Optimize."

Linearization

Linearized PDF (sometimes called "Fast Web View") rearranges objects so the first page's resources appear at the beginning of the file, followed by a hint table describing where subsequent pages live. A web browser can render page one while the rest of the file downloads. This is analogous to moving the moov atom to the front of an MP4 file. Without linearization, a PDF viewer over HTTP must download the trailer (at the end of the file), then the xref table, then seek backward for each page's objects.

PDF Subtype Standards

PDF/A restricts features to ensure long-term archival. No JavaScript, no external font references, no encryption, no transparency in PDF/A-1. All fonts must be embedded. ICC color profiles are required. PDF/A-3 relaxes one constraint: it allows embedding arbitrary files as attachments, enabling hybrid documents with source data inside.

PDF/X constrains output for print production. It requires specific color spaces (CMYK or spot colors), embedded fonts, bleed box definitions, and trapped status declarations. Output intent profiles guarantee consistent color reproduction across print facilities.

PDF/UA mandates accessibility. Tagged structure, reading order, alt text for images, and proper heading hierarchy are required. Most PDF generators do not produce PDF/UA-compliant output without explicit configuration.

Encryption and Security

PDF encryption operates at two levels. A user password prevents opening the file entirely — the content is encrypted with AES-256 (in modern implementations) and cannot be read without the key. An owner password restricts operations: printing, copying text, editing, annotation. Here is the critical distinction — owner password restrictions are enforced only by PDF viewer software and are trivially bypassable. Any tool that ignores the permission flags can print, copy, or edit an owner-password-protected file without knowing the password. The content itself is not encrypted by the owner password.

JavaScript Execution

PDF supports embedded JavaScript through the Adobe Acrobat SDK. Scripts can run on document open, page navigation, form field interaction, or print events. This enables interactive forms, calculations, and data validation. It also creates a significant attack surface. Malicious PDFs have exploited JavaScript execution to trigger buffer overflows, download malware, and execute arbitrary code. Most modern viewers disable JavaScript by default or sandbox its execution.

Gotchas

Font subsetting without a complete ToUnicode CMap produces files that render correctly but yield nonsense when text is copied or searched. Incremental updates can hide previous versions of content — a "redacted" document may still contain the original text in earlier revisions. PDF forms using XFA (XML Forms Architecture) are only fully supported in Adobe Acrobat; other viewers render them partially or not at all. Tagged PDF structure, needed for accessibility and reliable text extraction, is absent in most machine-generated PDFs.