Compression works by shrinking oversized images and stripping invisible overhead — so when a file barely moves after running through Compress PDF, it almost always means one of those two things wasn’t actually the problem. Here’s how to work out which, and what to do about each.
Check what’s actually inside the file
Mostly vector content — text, tables, drawn lines, logos built from shapes rather than photos — is already stored efficiently as instructions rather than pixels. There’s very little for a compressor to trim, so a 200-page contract that’s pure text might drop from 1.4 MB to 1.3 MB and that’s genuinely the ceiling, not a failed compression. If the file needs to be smaller anyway, the fix isn’t more aggressive compression — it’s splitting it into parts, since you’re fighting a page-count problem, not an image problem.
Already-compressed images are the other common case. A PDF built from JPEGs that were already saved at a low quality, or images a previous tool already re-encoded, have little room left to shrink further — re-compressing a lossy image a second time barely reduces size and can visibly degrade it. If you know the PDF passed through a compressor once already, running it through again is rarely worth doing.
A high page-count scanned document where every page is a full-resolution image is the case where compression should make a dramatic difference — 70–95% is typical. If a scan barely shrank, something else in the pipeline is likely the actual size driver — see the embedded content check below.
Something other than images or overhead is eating the space
- Embedded fonts, especially several full font families with every weight and style embedded rather than subsetted, can add meaningful size to a text-heavy document — this is usually a small contributor, but on a document with many custom fonts it adds up.
- Embedded video, 3D models, or attached files inside the PDF (uncommon, but it happens with interactive forms and some CAD exports) aren’t touched by an image compressor at all, because they aren’t images. If your file is unusually large for its page count, check whether it has attachments — most PDF readers show a paperclip icon or an attachments panel if so.
- A scanned PDF that’s already been OCR’d carries both the original page image and an invisible text layer. The text layer itself is tiny, so this is rarely the actual cause, but it rules out one possibility if you were wondering.
What to try, in order
- Split it. If the document is long and each page is reasonably sized, splitting into smaller files by chapter or page range solves an upload-limit problem without touching quality at all — often the fastest real fix when compression alone plateaus.
- Rescan at a lower setting, if you have the original paper document. 200 DPI black-and-white for text pages is indistinguishable from 400 DPI at reading size and starts several times smaller — the bloat is often baked in at the scanner, before compression ever runs. See Best Scanner Settings for OCR for the specifics.
- Send only the pages that matter. Delete pages you don’t actually need to include — a 40-page exhibit reduced to the 6 relevant pages is a bigger size win than any compression pass.
- Accept that some files are simply page-heavy, not bloat-heavy. A genuinely large, genuinely necessary document sometimes just has to be sent as multiple pieces.
One honest note
Our Compress PDF tool never hands back a file larger than what you uploaded — if there’s nothing left to trim, you get your original back rather than a wasted, worse copy. A result that looks unchanged after compressing isn’t a bug; it’s the tool telling you the file was already about as small as it can honestly get without cutting content.
Ready? Try the free Compress PDF tool now — no sign-up, no watermark, and your file is never stored.