What's actually inside a PDF file — an anatomy
8 min read
Why some PDF operations are instant and others nearly impossible, and where 'corrupted' files come from — all of it follows naturally from the file's internal structure.
A PDF is a warehouse of objects
Open a PDF in a text editor and you'll see a version marker like %PDF-1.7, followed by repeating blocks like “1 0 obj … endobj”. Each block is an object. A page is an object; so is a font, and so is an image — every one with its own number.
Objects refer to each other by number: “page object 3 uses font object 12 and image object 47”. The whole document is a tree of such references, and starting from the root — the catalog object — you can reach every page.
Page content is stored as drawing commands
A page's actual content lives in an object called a content stream. Inside are drawing commands: “move to coordinate (100, 700), at 12pt, draw these characters”. There is no notion of a paragraph or a table as in a word processor — it's closer to a recipe for laying ink on paper.
This is the root reason editing tables in a PDF, or converting one cleanly to Word, is hard. Nowhere does the file say “this is a table”; a tool has to reverse-engineer the structure from glyph coordinates.
The cross-reference table — why viewing is fast
Near the end of the file sits the cross-reference table (xref): an index recording the byte offset of every object. Thanks to it, a viewer can open a 500-page document and read only the objects for the requested page rather than the whole file.
It's why a huge PDF shows its first page instantly, and why browsers can display a PDF while it's still downloading.
What a “corrupted PDF” usually is
Many unopenable PDFs have intact content and a broken index. If a transfer truncates the end of the file, the viewer loses the map of where objects live even though the objects themselves are fine.
Recovery tools exploit this: ignore the index, sweep the whole file for “obj” markers, and rebuild the map. Unless the content itself is damaged, that often brings the file back.
Edit history can linger inside the file
PDF supports incremental saving: instead of rewriting the file on each edit, the changed objects and a new index are appended at the end. Saves are fast, and existing digital signatures survive.
The flip side: an incrementally saved file can still contain the content from before your edit. Even if you deleted something sensitive and saved, the earlier version may sit inside the file. Before external sharing, a full re-save into a fresh file is the safe move.
What this means in practice
Why merge, split, and rotate are fast and lossless: they move objects between files and fix up references, never redrawing content. Why “edit this table” and “convert to Word” are hard: they require inventing structure the file never had.
That's the boundary line between what tools can reliably do and what they can only attempt: is the job moving objects, or inferring structure?