How PDF Files Work

A PDF is a graph of numbered objects — pages, fonts, images — whose byte offsets are recorded in a cross-reference table at the end of the file. Viewers read the trailer, walk the page tree, and render. Damage the offsets and a tolerant viewer rebuilds the table by scanning; a strict one refuses the file.

Local-only

PDF looks like a page description format, and it is — but underneath it is a small database: numbered objects, any of which can reference any other. A font used on forty pages is stored once, a reused header image is stored once, and the pages themselves are nodes in a tree that says what to show and in what order.

The format has been an ISO standard since 2008 (ISO 32000, revised in 2017), and its core model has not moved since the 1993 original: a header, a body of objects, a cross-reference table recording where each object starts, and a trailer pointing at the root. Two decades of features layered on without shifting that foundation, which is why a viewer from today can open a scan from 1998.

Understanding the structure pays off immediately: it explains why merged files keep working, why deleted pages linger inside a file, why viewers disagree about damaged documents, and what a repair actually does. Every tool linked here — merge, split — performs that object surgery locally in your browser.

Merging is the structure lesson made visible, because a merge is the object graph being rebuilt: watch the the Merge PDF tool combine several files and you are watching new page-tree nodes get written and a fresh xref table laid down.

Extraction runs the same operation in reverse — deciding which objects the kept pages need — and the the Split PDF tool rewrites exactly those into a new file with its own cross-reference table, never touching your originals.

A graph of numbered objects

A PDF file opens with a header such as %PDF-1.7 and then is nothing but objects: blocks that start with a number, a generation number and the keyword obj, carry content, and end with endobj. Object 1 might be the catalog, the root of the document; object 2 the page tree; object 9 a content stream holding the drawing commands for one page. Any object can name another by writing its number and the letter R — 12 0 R — which is an indirect reference.

Indirection is the whole design. Everything is a reference, so structure is shared rather than copied: one catalog, shared resource dictionaries, and a 300-page document referencing the same embedded font through a single object. That also makes PDFs a genuine graph — which is why tools that manipulate them are doing graph surgery, not text processing.

The first two objects of a PDF

1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj

2 0 obj
<< /Type /Pages
   /Kids [3 0 R]
   /Count 1 >>
endobj

How the graph resolves

catalog (object 1)
└─ page tree (object 2)
   └─ page (object 3)

The page tree

Pages live in a tree, not a list: a root node of type Pages holds an array called Kids, whose entries are Page objects or further Pages nodes nesting the same way. Every child carries a Parent reference back up. A viewer finds page one by walking from the catalog down the first branch — and because nodes can be subtrees, inserting a 40-page section is one new node and one edited Kids array.

The tree is also where inheritance lives. MediaBox (the page's size), Rotate (its 90-degree viewing turns) and Resources (its fonts and images) may be declared once at a Pages node and flow down to every descendant that does not override them. A document whose pages are all A4 declares that size once at the root, which is why a single page object can be so short.

A page tree with inheritance

2 0 obj
<< /Type /Pages
   /Kids [3 0 R 4 0 R]
   /Count 2
   /MediaBox [0 0 595 842] >>
endobj

3 0 obj
<< /Type /Page
   /Parent 2 0 R
   /Contents 9 0 R >>
endobj

What page object 3 inherits

MediaBox  [0 0 595 842]   (A4, inherited)
Contents  9 0 R           (its own)

The xref table and the trailer

Near the end of the file sits the cross-reference table: one line per object, recording the byte offset where that object begins. An entry like 0000000123 00000 n says an object starts 123 bytes into the file; n marks it in use, f a free slot. A trailer dictionary follows, whose Root entry points at the catalog; then startxref records where the table itself begins, and the file closes with %%EOF.

The intent is random access. A viewer wanting page 240 does not read from the front; it seeks to the end, follows startxref to the table, and jumps straight to the bytes it needs. Everything about the format's tail structure — including why appending data is safe and prepending is not — follows from putting the map at the back of the territory.

Piece	Looks like	Role
Header	%PDF-1.7	Version stamp, first line of the file
Object	12 0 obj … endobj	One numbered node of content
Indirect reference	12 0 R	A pointer from one object to another
Xref entry	0000000123 00000 n	Byte offset where an object starts
Trailer	<< /Root 1 0 R >>	Points at the catalog; the document's root
startxref	startxref 12054	Byte offset of the xref table itself
EOF marker	%%EOF	End of the last update section

Incremental updates: append, never rewrite

When a PDF is edited — a form filled, a page deleted — a well-behaved writer does not rewrite the file. It appends: new and changed objects go at the end, followed by a new xref table and trailer describing the updated state, then another %%EOF. The original bytes stay untouched, and the new table supersedes the old.

That design is elegant for records — and it explains three real-world phenomena. Signed documents break when a tool rewrites them, because a signature covers specific bytes; an incremental update can preserve validity, a rewrite cannot. Deleted content lingers: a page you removed usually still sits in the file, unreferenced by the latest table but readable to anyone who scans. And files grow with every save, since nothing is reclaimed until a full rewrite — which is what cleaning or linearising performs.

Why some viewers repair broken files

The xref table is the format's load-bearing wall and its favourite failure point. A file emailed as text (which corrupts binary bytes), truncated by a failed transfer, or written by an over-promising tool can end up with offsets that point at the wrong places. When the viewer follows startxref and finds nonsense, the file is broken — by the book.

What happens next is a policy decision, not a spec requirement. Tolerant viewers invoke a rebuild: they scan the whole file for anything shaped like a valid object header (a number, a generation, the keyword obj), collect what they find into a fresh in-memory xref, and open the document anyway. Recovery is slow on large files and can misjudge ambiguous objects, but it usually works — which is why Acrobat offers to repair while stricter viewers simply refuse. Anything that writes a PDF back out ends the ambiguity by producing a clean table over exactly the objects it kept.

Viewer behaviour	What it does	Trade-off
Strict	Refuses the file when xref or startxref is wrong	Fast, honest, unhelpful for recovery
Tolerant	Scans for obj markers and rebuilds a table in memory	Slow on big files; may guess at ambiguity
Rewriting tools	Write a new xref over the objects they kept	Removes the ambiguity; new file, new offsets

Linearisation and font subsets

Two refinements complete the picture. A linearised PDF — marketed as Fast Web View — has its objects physically reordered so page one's come first, plus a hint table that lets a viewer start rendering before the rest arrives. Nothing about the document's logic changes; only the layout on disk does, which is why linearisation is a full rewrite and why it cuts first-paint time on slow connections and byte-serving servers.

Fonts follow the same sharing philosophy: an embedded font is one object referenced by every page that uses it, and well-behaved writers embed only the glyphs actually used — a subset. A 40-page report often carries tens of kilobytes of font data instead of megabytes. The cost is that text extraction depends on the subset's ToUnicode map; without it, viewers show the glyphs perfectly while copy-paste yields garbage.

Frequently asked questions

Is my PDF uploaded when I merge or split it here?

No. Parsing, page-tree surgery and xref rewriting all happen in your browser tab; the file never leaves your machine. Verify it in DevTools: open the Network panel, merge two files, and watch the request list stay empty. The site's Content-Security-Policy also blocks outbound connections from page scripts.

Why did my PDF get bigger after I deleted pages?

Because a well-behaved editor appends rather than rewrites: the new xref table marks the pages gone, but their objects still sit in the file, unreferenced and unreclaimed. The removed content may also still be recoverable from the old bytes — worth knowing if the document was ever sensitive. A full rewrite is what actually shrinks the file.

Can a corrupted PDF be repaired?

Often. Most damage is a broken xref table or startxref pointer, and tolerant viewers rebuild the table by scanning for valid object headers. What cannot be recovered is what the scan cannot find: objects overwritten by binary corruption or truncated mid-body are simply gone. That is why repair sometimes yields a partial document — the honest limit of the scan.

Why does copy-paste produce garbage from some PDFs?

Text is drawn with glyph codes, not letters, and recovering letters depends on a ToUnicode map shipped with the embedded font. Subset fonts without a good map render beautifully but paste nonsense, and scanned pages have no text at all until OCR invents it. If a PDF pastes badly, rendering is fine — the glyph-to-character mapping is what is missing.

What does a linearised PDF mean, and do I need one?

Linearisation (Fast Web View) reorders the file so page-one objects come first and adds a hint table, letting viewers render before the whole file arrives. It changes delivery, not content. It matters when PDFs are served over networks with byte-serving; opened locally it changes nothing visible, though it does produce a tidy, fully rewritten file as a side effect.

Why does the same PDF look different in different viewers?

ISO 32000 leaves deliberate latitude: font substitution when an embedded font is missing, viewer-specific handling of damaged structures, colour-management defaults and transparency rendering. A PDF with subsets embedded and no damage renders nearly identically everywhere; drift appears when files rely on local fonts or carry structural problems that each viewer resolves its own way.

ToolsByUs team · How we check our tools