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.
Mostly vector content — text, tables, drawn lines, logos built from shapes rather than photos — is already stored efficiently as instructions rather than pixels, so there’s very little for a compressor to trim. 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, and re-compressing a lossy image a second time barely reduces size and can visibly degrade it, so 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 — so if a scan barely shrank, something else in the pipeline is likely the actual size driver.
That something else is usually one of three things. 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 — 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, since most PDF readers show a paperclip icon or an attachments panel if so. And 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, roughly in order: split it, since 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, since 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, since a 40-page exhibit reduced to the 6 relevant pages is a bigger size win than any compression pass. And 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.
If the destination is an email rather than an upload form, How to Share Large Documents Without Email Attachment Limits covers the options once compression has genuinely run out of room.
Run it through the free Compress PDF tool again with the tips above in mind — no account required, no watermark, and nothing saved on our end.