How Does PDF Page Extraction Work? The Object Tree and Shared Resources

What happens behind the scenes when you extract three pages from a PDF? Pages aren't cut and pasted, because a "page" in PDF isn't a single object. This article looks inside the format to explain why extraction is so fast, why the file you extract sometimes stays unexpectedly large, and why something happens to bookmarks and links.

Inside a PDF: objects and references

A PDF file is a collection of numbered objects. Each object has a number and objects reference each other by number. Roughly, you find these:

• The catalog: the document's root object. It says "the page tree is in that object, the outline is in this one."
• The page tree: a tree structure holding the pages in order.
• Page objects: each represents one sheet. They carry not content but references: "my content is in that object, my resources are in this one, my size is this."
• The content stream: the sequence of commands describing how the page is drawn.
• Resource objects: fonts, images, color profiles, transparency groups.

The critical point: a page object doesn't hold content, it points to it. And multiple pages can point to the same resource. An embedded font used in the document is a single object; all 300 pages reference it. If a corporate logo appears at the top of every page, there's one image object in the file and 300 pages look at it.

That sharing is the fundamental mechanism keeping PDFs at a reasonable size — and, as we'll see shortly, the reason behind post-extraction size surprises.

What extraction does, step by step

When you say "extract pages 10-12," the tool does this:

1. It walks the page tree and finds the page objects at the requested indices.

2. It does dependency tracking. Starting from each selected page object, it follows everything it depends on: the content stream, the fonts that stream uses, images, color spaces, annotations, form fields. It's like a reachability scan on a graph — you start at the root and mark every node you can reach.

3. It copies the reachable objects into the new file. During copying, object numbers get reassigned, because numbering starts from scratch in the new file. References are updated accordingly.

4. It builds a new catalog and page tree. The new page tree has only three pages, arranged in order.

5. It rewrites the cross-reference table (xref). That table says which byte of the file each object starts at; it saves the viewer from scanning the entire file to find an object.

None of these steps involves image processing. No JPEG is re-encoded, no text is redrawn. The operation is essentially copying and renumbering — which is why it's both very fast and absolutely zero quality loss.

The size surprise explained

Now to the most frequently asked question: you extracted 2 pages from a 300-page, 40 MB file and the result is 4 MB. Why?

The answer is in step two: dependency tracking. If the page you extracted uses the document's embedded font, that font object has to be copied into the new file. A complete font family with broad character support (regular, bold, italic, bold-italic) easily runs to 2-3 MB. If there's a full-page photo on the page, that carries across as it is too.

| Resource type | Effect on the extracted file | |---|---| | Embedded font (full) | All of it carries over, can be megabytes | | Embedded font (subset) | The subset carries over, smaller | | Images on the page | Carried as they are, quality unchanged | | ICC color profile | Carried, a few hundred KB | | Unused resources | Not carried, discarded |

Some tools go a step further and "re-subset" the embedded font — keeping only the characters that appear on the extracted pages. That gives a serious reduction but is a heavier operation and not every tool does it.

If size matters to you the practical solution is simple: after extraction, run the file through a compression tool once. Compression discards unused resources, re-encodes images and recompresses streams.

What happens to bookmarks and links

The document's outline tree lives at the catalog level and each of its entries points to a target: "Chapter 3 → page object 147".

When you extract 3 pages, nearly all of that tree's entries point to pages that are no longer in the file. A bookmark with a broken target does nothing when clicked, or makes the viewer throw an error. Some tools try to filter and carry over the surviving entries; the result is usually a tree of two headings with a broken hierarchy, creating more confusion than benefit. That's why many applications prefer to discard the outline entirely.

The same logic applies to internal links. If the target of a "See Appendix B" link wasn't extracted, the link breaks. External links (URI actions pointing to a web address), by contrast, keep working fine because they aren't tied to any page.

Form fields are in an interesting middle position. The field itself is an annotation attached to the page, so it carries across. But the form's field dictionary (AcroForm) is at document level and can contain calculation or validation logic across fields. When you extract part of a multi-page form, the fields appear but the logic can be broken.

The page number dilemma

In the file you extracted, the page counter starts at 1 — that comes from the order in the page tree. But the "47" printed on the page is part of the content stream: it's a text drawing command. Because extraction doesn't touch the content stream, that number stays exactly as it was.

So the first sheet of your new file may say "47" at the bottom. That isn't an error, it's the natural consequence of the format. If you want to fix it there are two routes: print a new numbering (which appears next to the old number), or cover the old one with a white box using an editing tool and add a new number.

Some PDFs also contain page label definitions — a document-level structure that makes the viewer show custom labels like "iv" or "A-3" in its page box. These usually don't carry over during extraction.

Why it can be done in the browser

None of the steps above involves heavy computation. Reading objects, following dependencies, renumbering and writing — these are all memory and file operations. A modern browser does this quickly even on files of several hundred pages.

The practical consequence: your file goes to no server. If you're extracting signature pages from a confidential contract or pulling the relevant sheet out of a medical report, the document never leaves your device. And because there's no upload-download wait, the operation is fast regardless of file size.

The limit is the memory a browser tab can use. On very large files (hundreds of megabytes, thousands of high-resolution pages) you can hit memory pressure; in that case splitting the file roughly first and then extracting eases things.

In summary

Page extraction is a reachability scan over a PDF's object graph, copying everything the selected pages depend on into a new file. Because no content is re-encoded, quality loss is zero and the operation is very fast. In exchange, because shared resources (especially embedded fonts) have to be carried across, the output can stay disproportionately large; compression solves that. Bookmarks, internal links and page labels that live at document level, meanwhile, can't survive this operation by their very nature — their targets are no longer in the file.