Why you can't work out a PDF's size by adding up its pages

Take a 60 MB PDF with 100 pages and cut it down the middle. You’d expect two files of roughly 30 MB each. What you actually get might be 44 MB and 21 MB, and the two together weigh more than the original you started from.

This trips people up constantly, and it’s the reason splitting a PDF by size is a harder problem than it looks. There is no such thing as “the size of page 7”.

A PDF isn’t a stack of pages

The mental model most of us carry around is a paper one: a document is pages, pages are sheets, sheets stack up. A PDF file doesn’t work like that at all.

Inside the file is a pool of numbered objects, and pages are just some of them. A page object is tiny. It’s mostly a list of references: use font 12, use image 47, here’s a content stream with the drawing instructions. The heavy things live once in the pool, and every page that needs them points at the same copy.

So an embedded font is stored one time, no matter whether 2 pages or 200 use it. A logo in the letterhead of every page is one image object referenced ninety times, not ninety images. Colour profiles, ICC data, shared form XObjects: same deal.

Now ask again how much page 7 weighs. Does it own a share of the font? All of it, or a hundredth of it? The question has no answer, because the bytes aren’t attributable to a page in the first place.

Two consequences that pull in opposite directions

Pages are cheaper together than apart. Three pages that use the same embedded font in one file carry that font once. Put each in its own file and you’ve got three copies. This is why splitting adds weight overall: shared resources get duplicated into every part that needs them. On a text-heavy report with a couple of big embedded font families, the sum of the parts can be noticeably fatter than the original.

One page can be enormously expensive. A page with a 12 MB photo drags all 12 MB into whichever part holds it. Its neighbours might be 40 KB each. That’s why parts come out uneven: 60 pages in one, 2 in the next, because the tool is packing bytes and not pages.

Compression happens at the end

There’s a second layer. When a PDF is written out, small objects get bundled into object streams and deflated together, and the cross-reference table gets compressed alongside them. How well that goes depends on what’s in the bundle. A hundred similar page objects compress beautifully as a group; ten do less well proportionally.

Which means the size of a set of pages isn’t even fixed until you’ve decided what else is going in the file with them. There’s no formula. There’s only writing the file and looking at how big it turned out.

So the tool actually saves the file

That’s the design decision behind the tool: it doesn’t estimate, it builds a real PDF from a candidate range of pages, saves it, and reads the byte count. The number in the results table is that measured number, and the bytes you download are the same bytes that were weighed. Nothing gets re-saved afterwards with different settings, because measuring with one set of options and shipping with another gives you a figure that means nothing.

The catch is cost. Saving a document isn’t free, and the naive version of this gets ugly fast.

Finding the cut without melting the tab

The obvious approach: try 1 page, save, still fits; try 2, save, still fits; try 3… and stop when you go over. For a part that ends up holding m pages that’s m saves, and each save serialises up to m pages. Do that for a whole document and you’re at quadratic cost in bytes moved. On a 300-page file it’s the sort of thing that freezes a tab for half a minute.

Instead the tool gallops, then bisects:

1. Gallop. Try 1 page, then 2, then 4, 8, 16, doubling until a candidate blows past the limit. Now you know the answer sits between the last size that fit and the first that didn’t, and it took about log₂(m) saves to get there.
2. Bisect. Binary search that interval for the largest page count that still fits. Another log₂(m) saves.

Roughly 2·log₂(m) saves per part instead of m. For a 64-page part that’s about a dozen saves rather than sixty-four, and the total bytes serialised across the document drops from quadratic to n·log m.

Bisection assumes adding pages never makes a file smaller. That’s true except in pathological cases, and there’s a safety net regardless: the part you download is the buffer that was measured, not a reconstruction, so even a weird document can’t sneak a file past the limit.

The page that fits nowhere

If a single page is heavier than the limit on its own, there’s no move left. Pages don’t subdivide. That page goes into a part by itself and gets flagged as oversized in the results table before you download anything, with a warning naming the page number.

Getting handed a file over the limit with no warning is how you end up sending the same failing email twice, so the flag is the point. When you hit one, the fix is upstream: shrink the page. Scanned pages are usually the culprit, and compressing first often makes the whole problem go away.

What to take from this

If you need parts of a specific weight, splitting by size is the tool for it, because it measures instead of guessing. If you need parts with specific content, page 1-12 as one document and 13-40 as another, that’s a different job and splitting by page range does it directly.

And don’t be surprised when the parts come out lopsided, or when they add up to more than you started with. That’s the file format being honest about how it stores things.