It's a reasonable-sounding assumption that turns out to be wrong: splitting a large PDF into smaller pieces should make each piece proportionally smaller, right? The reality is a bit more nuanced, and understanding why clears up a common point of confusion about what splitting actually does and doesn't accomplish.
What actually determines a page's file size
A page's contribution to a PDF's total file size comes from what's actually on that page — primarily embedded images, fonts, and any other resources, rather than some fixed "per-page" cost. A single image-heavy scanned page can be many times larger than ten pages of plain text combined, which means extracting "one page" from two different documents can produce two very differently sized results, depending entirely on that specific page's content.
Why extracting fewer pages produces a roughly proportional, not dramatic, size reduction
Extracting half of a document's pages generally does produce a file roughly half the original size, since you're keeping roughly half the content — this part matches intuition correctly. What doesn't match intuition is expecting the remaining pages to somehow compress further or shrink beyond their proportional share, since splitting doesn't apply any additional compression; it simply copies the selected pages' existing data into a new file exactly as it already was.
Shared resources and why extraction sometimes doesn't shrink as much as expected
PDFs can share certain resources, like a font, across multiple pages, storing that shared resource once rather than duplicating it on every page that uses it. When you extract only some pages, a shared resource used by pages both inside and outside the range still needs to come along for the pages that are being kept, which occasionally makes an extracted file slightly larger, proportionally, than a naive per-page calculation would suggest, though this effect is usually minor.
What actually reduces file size: compression, not splitting
If the goal is genuinely reducing file size — not just extracting fewer pages, but making the resulting file smaller for its own sake — that's a compression task, covered in more detail in this site's compression-focused guides, not something splitting accomplishes on its own. Splitting and compressing are two entirely separate operations that solve different problems: one changes which pages exist in a file, the other changes how efficiently those pages' existing content is stored.
A quick example to make this concrete
Extracting 5 pages from a 50-page, 10MB scanned document produces a new file roughly one-tenth the size, around 1MB, simply because it contains one-tenth of the original content. But if those specific 5 pages happen to be the most image-heavy ones in the whole document, the extracted file could actually be a larger fraction of the original than 5/50 would suggest, since it's carrying a disproportionate share of the heavy content.
Try the Split & Extract tool yourself — free, instant, nothing uploaded.
Open the toolFrequently asked questions
If I split a 100-page PDF into 10 files of 10 pages each, will they add up to the original size?
Very close to it, yes — the combined size of all the split pieces will be roughly equal to (sometimes very slightly more than) the original file's size, since splitting doesn't remove or compress any content, just separates it.
Does extracting fewer pages always produce a proportionally smaller file?
Roughly, but not exactly, since file size depends on each specific page's content (mainly images and fonts) rather than a fixed per-page cost — extracting image-heavy pages produces a larger result than extracting the same number of text-only pages.
How do I actually make a PDF smaller if splitting doesn't do it?
Through compression, which reduces the size of the images and other resources within the pages themselves, rather than changing which pages exist in the file — this is covered in more detail in the compression guides on this site. Keeping this distinction clear — splitting changes which pages exist, compression changes how efficiently they're stored — avoids reaching for the wrong tool when file size is the actual goal.
Does the order I list pages in a range affect the resulting file size?
No, reordering which pages are included doesn't change the total file size meaningfully, since size is driven by each page's actual content, not the sequence they're arranged in within the new file. Once this distinction is clear, it becomes much easier to predict roughly how large an extracted file will be before actually running the extraction, simply by considering what kind of content the selected pages contain.
