Every "compress PDF" tool makes the same trade: smaller file, worse document. Images get recompressed, 300-dpi scans drop to 150, text sometimes gets rasterized, and the output is a re-rendered artifact of the original. Often the better move is not shrinking the document at all — it's cutting it into right-sized pieces that are each byte-faithful to the original.
What actually makes PDFs heavy
A PDF's size is dominated by embedded images. Text and vector pages cost a few KB each; scanned or photo-heavy pages cost 0.5–3 MB each. That skew is why compression disappoints (the images are already JPEGs — recompressing them mostly just degrades them) and why splitting works: removing heavy pages removes their megabytes entirely.
Fonts complicate the math slightly: each output part embeds the fonts its pages use, so ten parts of a text-heavy file can sum larger than the original. For scan-heavy files — the ones with size problems — this overhead is noise.
The math can also run the other way. PDFs edited in Acrobat and similar apps are often saved incrementally: changes are appended to the end of the file and the superseded objects stay behind, unreferenced but still taking up bytes. Splitting rebuilds each part from only the objects its pages reference, so that dead weight disappears — it's common for the parts of a heavily edited file to sum to less than the original.
When splitting is the right tool
- Upload and attachment caps. Portals and mail servers with 10–25 MB limits accept three 9 MB parts happily. See attachment limits by provider.
- Only part of the document is needed. The fastest size reduction is sending 6 relevant pages instead of 120. Extract exactly those pages.
- Archives with per-file quotas. Court e-filing systems, university submission portals, and CMS uploaders often cap per-file size but not file count.
- Quality is non-negotiable. Signed contracts, sealed drawings, medical imaging reports — anything where "slightly degraded" equals "unusable."
When compression genuinely wins
Honesty department: if the recipient needs one file and doesn't care about fidelity — a slide deck for quick reference, a scanned receipt — compression is the right call. Splitting can't make one file smaller; it makes several smaller files.
Estimating part sizes
If the goal is simply "every part under X MB", skip estimation entirely: Split PDF by Size measures each candidate part's real serialized size and finds the largest run of pages that fits, including an email mode that allows for base64 overhead. The manual method below is still useful when you want parts to follow the document's structure — chapters, exhibits — rather than pure size.
File size rarely divides evenly by page count, because heavy pages cluster (the photo appendix, the scanned exhibits). A practical loop:
- Note the total size and page count — say 48 MB, 120 pages (0.4 MB/page average).
- In the PDF splitter, start with Every N pages where N = target ÷ average — for a 10 MB target, N = 25.
- Check the actual outputs. If part 3 (the one with the scans) came out at 18 MB, re-split with uneven ranges instead: give the scan section its own smaller chunk, like
1-40, 41-60, 61-80, 81-120.
Two passes gets you within limits essentially every time.
Because split.tools rebuilds the PDF in your browser, you can iterate on N as many times as you like at zero cost — no upload queue, no per-file pricing, no server seeing your document. Try the splitter.