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.
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
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.