· 5 min read

The document needs a sandbox

PDF preserves the page by making every reader parse a programmable container, infer missing semantics, and defend itself against malformed or active content.

A researcher in safety glasses examines a small sample held in tweezers through the sealed glove ports of a laboratory glovebox.
UCL Mathematical & Physical Sciences, CC BY 2.0

I hate PDFs most when someone sends three paragraphs inside one. You click what should be text and a second application wakes up inside the browser, complete with its own zoom, search, selection model, print path, keyboard behavior, and accessibility tree. The page can look finished while the document underneath is missing.

A PDF is an application container shaped like a page. The format won by freezing appearance across printers and operating systems, then kept absorbing forms, scripts, attachments, signatures, encryption, layers, annotations, and logical structure until opening a memo became a parser problem and a security boundary.

The page outranks the reading#

Adobe's own accessibility documentation separates rendering order from logical order. Characters can be painted in one sequence and read in another, so Tagged PDF carries an additional structure tree for headings, tables, links, form fields, and the order assistive technology should follow. Untagged files leave Acrobat inferring that structure “to some extent,” with results Adobe describes as less satisfactory.

The current W3C reading-order technique for PDF warns that complex layouts can convert with the wrong tag order and may need manual repair in Acrobat Pro. A lunch menu should not need remediation software. Yet a two-column page can look flawless while a screen reader alternates lines between columns because the semantic document was never finished.

PDF carriesSoftware must expose or inferFailure when it cannot
Painted textWords, Unicode, selection boundaries, and reading orderColumns interleave or copied text arrives in file order
Tagged structureHeadings, lists, tables, alternative text, and focus orderAssistive technology receives a flat or misleading document
Scanned pagesOCR, language detection, and confidence about inferred textThe apparent document remains a sequence of pictures
Actions and attachmentsViewer policy, prompts, scripting, URL handling, and file handlingUseful features disappear or active content becomes attack surface
The visible page and the usable document depend on different layers of the file and different reader subsystems.

So whether a given PDF is readable depends on everything that happened upstream — how the source was structured, which export settings were used, whether anyone checked the tags. The PDF/UA standard defines a disciplined accessible subset, and good tools can produce it. But the .pdf extension looks the same either way, and you learn which kind you were sent after you open it.

The file grew verbs#

A PDF catalog can point at the page tree and also at forms, embedded files, a logical structure tree, and an action to run when the document opens. This representative object is enough to show why a viewer grows into a runtime:

representative PDF catalog
1 0 obj<< /Type /Catalog   /Pages 2 0 R   /AcroForm 8 0 R   /Names << /EmbeddedFiles 9 0 R >>   /StructTreeRoot 10 0 R   /OpenAction 11 0 R>>endobj
  1. 1The page tree leads to the content that gets painted.
  2. 2AcroForm adds interactive fields and their behavior.
  3. 3The names tree can expose files carried inside the PDF.
  4. 4The structure tree supplies semantics separately from page paint.
  5. 5OpenAction lets the file request work as soon as the viewer opens it.
One catalog dictionary can connect page rendering, interaction, attachments, accessibility structure, and document-open behavior.

Why can a memo have an open action? Adobe's action reference includes JavaScript, application launch, movies, sounds, form submission, links, and imported data. Modern viewers restrict or ignore parts of that list, but they still have to recognize enough of the machinery to decide what to allow. Acrobat's JavaScript guide describes APIs for attachments, databases, document security, and interactive forms.

Everyone writes a reader#

Firefox ships PDF.js, whose core parses and interprets the binary file before separate display and viewer layers render it. Chromium carries PDFium. Desktop and server software rely on projects such as Poppler and MuPDF. Each engine has to survive fonts, images, compressed object streams, annotations, malformed files, text extraction, and the features its product chooses to expose.

A file format that needs a sandbox has become software. PDFium maintains dedicated security guidance alongside corpus, JavaScript, pixel, and fuzz testing, while Adobe keeps publishing Reader patches. Its June 2026 security bulletin fixed critical and important vulnerabilities whose possible effects included arbitrary code execution, denial of service, and memory exposure.

I am not claiming PDF is uniquely dangerous among complicated parsers; browsers, archives, and media codecs need hardening too. What bothers me is how we treat the file. We email PDFs as inert sheets of paper, then ask a constantly patched interpreter to open them safely and guess which painted marks were meant to be prose.

Keep it at the edge#

PDF still earns its place as a print-ready artifact, signed form, archival snapshot, or press proof. Those jobs value stable pages. A public report meant for reading should begin as structured HTML or another semantic source, with PDF offered as a secondary download and generated with tags that somebody actually checks.

Adobe's word-finding documentation offers two ways to enumerate recognized words: file order or page location. It then warns that page location generally matches reading order for one column and fails for multiple columns. The page has already rendered perfectly by the time the library starts guessing how its words become a sentence.