What Is Inside a PDF File? A Guided Tour of the Format
Open a PDF in a plain text editor and the first line is a small confession: %PDF-1.7, followed by a burst of binary noise. That header marks the start of a container format standardised as ISO 32000, and container is exactly the right word. A PDF is not a picture of a document, and it is not a word processor file either. It is a small database of numbered objects plus a set of instructions for drawing them onto pages. Understanding that structure explains almost every strange behaviour you have ever seen from a PDF, from why page 400 opens instantly to why a half-downloaded file refuses to open at all.
The body of the file holds indirect objects, each carrying an object number, a generation number and a payload. Some objects are dictionaries, which are simple key and value maps describing a page, a font, or the document catalogue that sits at the root of the tree. Others are streams: blocks of compressed bytes holding the real content, such as the drawing operators for one page, an embedded font program, or a JPEG. A page object is mostly a bundle of references pointing at this box, that font and this content stream, so the page itself is tiny while the heavy data lives in shared objects that many pages can reuse.
After the body comes the cross-reference table, the most under-appreciated part of the format. It is an index mapping every object number to a byte offset inside the file, and the trailer at the very end tells the reader where that index begins and which object is the catalogue. This is why readers effectively open a PDF from the back forwards, and why a 900-page document can jump straight to page 850 without parsing the 849 pages before it. Random access is a structural property of the format itself, not a clever optimisation that your viewer bolted on afterwards.
Because the index lives separately from the data it describes, the index is what breaks first. Truncate a download, resave a file through a buggy writer, or let a tool append content without updating offsets, and every object may still be sitting there intact while the map to them points at the wrong bytes. Readers then show a vague damaged file warning even though the content survives. The same separation is what makes incremental saving possible: an editor can append new objects and a fresh cross-reference section at the end of the file, leaving the original bytes completely untouched.
The practical payoff is that most so-called corrupt PDFs are recoverable. A repair pass ignores the broken table entirely, scans the whole file for object markers, and rebuilds the index from whatever it finds. That is exactly what the repair tool does, and it is also why merge and split are such cheap operations: they copy object trees and write a new cross-reference table instead of re-rendering any pages. Because PdfWill runs these engines as WebAssembly inside your own browser, a confidential file that will not open never has to be uploaded to a stranger's server to be rescued.