tooldura
PDF Tools

Splitting a PDF: Why the Parts Weigh More Than the Whole

T
tooldura editorial
8 min readUpdated October 27, 2026Open tool →

Split a 40-page report into one file per page and the folder that comes out is often two or three times the size of the report. Split a scanned contract the same way and the parts add up to almost exactly the original. Occasionally the parts come out smaller than the file they came from. All three results are correct, and the reason is the same each time: a split does not slice the file at page boundaries, it copies pages into new documents, and a page drags along whatever it depends on.

A Split Copies Pages Out, It Does Not Cut the File

ISO 32000-2, the PDF standard, stores a document as numbered objects. Pages sit as leaves of a page tree, and each page points at what it needs: one or more content streams with the drawing instructions, and a resource dictionary naming the fonts, images and graphics states those instructions use. Several pages can point at the same font or the same image, and that sharing is where most of a PDF's efficiency comes from.

Some page attributes are not stored on the page at all. Section 7.7.3.4 lets a page inherit its resources, its MediaBox (paper size), its CropBox and its rotation from the page-tree node above it, so a hundred-page file can state "A4, rotated 90 degrees" once rather than a hundred times. A page copied out on its own loses that parent, so a correct split writes those inherited values onto the page itself. A careless one produces pages with no size or with the wrong orientation, which is the main thing worth checking if a split file opens looking strange.

Each part then gets a brand-new catalog, page tree and trailer. Nothing is cut and glued: the new file is written from scratch around the copied pages.

Where the Bytes Go When a File Is Split

What happens to each kind of object when one document becomes several. Section numbers refer to ISO 32000-2.

ObjectIn the originalAfter splitting
Page content streamsOnce per pageOnce, in the part that holds the page
An image used on one pageOnceOnce
A logo repeated on every pageOnce, sharedOnce in every part
Embedded font program (9.9)Once, sharedOnce in every part that uses it
Old object versions from incremental saves (7.5.6)KeptDropped
Objects nothing refers toOften keptDropped
Outline, form fields, attachmentsHeld by the catalogDropped

Why the Parts Usually Weigh More

Fonts are the usual cause. A PDF that will display the same everywhere embeds the font programs it uses, normally as a subset holding only the glyphs that appear in the document. You can spot a subset by its name: section 9.6.4 has it carry a six-letter tag and a plus sign, as in ABCDEF+Calibri. In the original that subset is stored once and every page refers to it.

Split the file and each part needs its own copy, because a PDF cannot borrow resources from another file. The copy each part gets is the whole subset from the original, not a smaller subset for just its own pages, since the copier moves objects and does not rebuild fonts. Take a report with three embedded fonts of 60 KB each and split it into 20 files: the fonts that cost 180 KB once now cost 180 KB twenty times, about 3.6 MB, on top of the text itself. That is how a 2 MB report becomes a folder of nearly 6 MB.

Scans behave differently. Every scanned page is its own image and shares nothing with its neighbours, so each image simply moves into the part that holds its page. The parts of a split scan add up to the original plus a few kilobytes of new structure per file.

And Why They Sometimes Weigh Less

PDF allows incremental updates (section 7.5.6). When an editor saves a change, it may append the changed objects and a new cross-reference section to the end of the file instead of rewriting it. The old versions stay in the file, unreachable but present. A form filled in and saved ten times, or a contract annotated by three reviewers, can carry several copies of its own pages.

A split only writes what the copied pages actually reach. The old versions, the deleted pages and the thumbnails nobody displays are left behind, so a heavily edited file can come out of a split smaller than it went in. If a file seems much too large for what it shows, splitting it into one part covering every page is a crude but effective way to see how much of it is history.

🔗

Links between pages need their target in the same file

A table of contents, a "see page 14" link or an index entry points at a page object. After a split, the link works only if the page it points at landed in the same part. Links to pages in other parts are switched off, which is the right outcome: a naive copier follows them and silently packs the target pages, images and all, into the file as invisible dead weight. A contents page split on its own can otherwise come out nearly as large as the whole document. Links that go to a named destination rather than to a page break in every part, because the names live in the original's catalog.

Cut your PDF where you choose

Split every few pages or between any two, or extract only the pages you need.

Open Split PDF →

Three Reasons to Split, and How to Set Each One Up

Most splits fall into one of these, and each wants a different setting.

1

A scanned batch that is really several documents

A document feeder turns a stack of invoices into one long file, with nothing in it to say where one invoice ends. Neither a fixed page count nor a range typed blind gets this right when the invoices vary in length. Look at the pages and cut at each first page by hand. Thumbnails are enough for letterheads and logos. Plain text pages all look alike at that size, so open each one at full size before you cut.

2

Documents of the same length, end to end

Mail-merged letters, a stack of two-page application forms, payslips printed in one run: when every document has the same length, a cut every N pages does the whole job in one step. Check the first and last parts before trusting it. A single blank or missing page anywhere in the batch shifts every cut after it by one.

3

A file too large to send

Email providers cap attachments at around 20 to 25 MB, and some count the size after encoding. Base64, which RFC 2045 uses to carry binary files in email, adds a third, so a 20 MB PDF can travel as more than 26 MB. If the file is a scan, splitting it in half roughly halves each part. If it is mostly text with embedded fonts, halving it does less than you expect, because both halves carry the fonts. Compressing the images before they go into the PDF is often the better fix.

What the Parts Do Not Inherit

Everything drawn on a page comes through: text that stays selectable, images at their original compression, vector graphics, web links and rotation. What belongs to the document as a whole does not, because it hangs off the original's catalog and the parts are written with catalogs of their own.

That means no bookmark outline, no interactive form fields, no file attachments, no tagged structure for screen readers and no document-level metadata beyond a fresh title. A digital signature does not survive either, and should not. It covers the exact bytes of the signed file, and a part is a different file. Split a signed contract when someone needs one schedule from it, but keep and send the original whenever the signature is the point.

Frequently Asked Questions

Found this guide useful? Pass it on.

Related Tools

Keep Reading