"Why did my PDF only shrink by 5%?" is one of the most common frustrations with compression tools — and it usually comes down to a misunderstanding of what's actually inside a PDF file, and what the specific tool you're using actually does to it.
A PDF Is a Container, Not a Format
A PDF file isn't one type of data — it's a container that can hold text, vector graphics, embedded fonts, and raster images, all at once. Compression tools can only meaningfully shrink the parts they're built to touch. That means the result depends both on what's inside your specific file and on whether the tool you're using actually recompresses images or only optimizes the surrounding structure.
The Two Types of PDFs, and Why They Compress Differently
Text-based PDFs (exported from Word, Google Docs, or a code editor) are mostly vector text and structural data. This kind of content is already extremely compact — a 50-page text document might only be a few hundred KB to begin with, and there often isn't much left to compress. If a compressor reports a tiny reduction on a document like this, that's usually not a bug — the file was already near its minimum size.
Image-heavy PDFs (scanned documents, exported presentations, photo-based reports) are a completely different story. A single uncompressed scanned page can easily be 5-10 MB. A tool that actually recompresses embedded images at a lower quality/resolution can shrink a file like this by 70-95% with minimal visible quality loss — but only if it does that recompression step. Not every "PDF compressor" does.
Two Fundamentally Different Approaches, and What Ours Does
There are two distinct things a PDF compressor can do, and they have very different effects:
- Re-encode embedded images at a lower quality setting or reduced resolution, then reassemble the PDF with the smaller images. This is the approach that produces the dramatic 70-95% reductions on scanned documents — but it's real, lossy work on the image data, and it requires a proper image-processing pipeline.
- Optimize the PDF's internal object structure (grouping fonts, page dictionaries, and other structural objects into compressed object streams) without touching embedded images at all. This is safe and lossless — nothing about image or text quality ever changes — but it only shrinks the structural overhead, not the images themselves.
Our own PDF Compressor currently does #2, not #1. It won't meaningfully shrink a scanned document — the images pass through byte-for-byte — but it also carries zero risk of visible quality loss, and it can genuinely help on documents with heavy structural overhead (lots of form fields, embedded fonts, or annotations). If you need a scanned PDF to actually shrink by a lot, that requires the image-recompression approach above, which today means reducing image quality before or outside the PDF step (see the workflow at the end of this article).
Why This Distinction Gets Lost
Most SEO copy for "PDF compressor" tools — including, until this article was corrected, our own — describes the image-recompression outcome (70-95% reduction) as if every tool that reduces PDF size achieves it. It doesn't. Before trusting a specific tool's claimed compression ratio, it's worth checking (or testing with a real scanned file) whether it's actually re-encoding images or just repacking structure — the two produce wildly different results on the same input file.
If Your Compressor Does Support Quality Levels
Tools that implement real image recompression usually expose a quality slider, and the same pattern shows up almost everywhere: going from "high" to "medium" quality shrinks a file dramatically, while going from "medium" to "lowest" barely helps further and starts visibly degrading images — which is why most such tools default to a sensible middle setting. Our own Compress PDF doesn't have this slider at all, because it doesn't recompress images (see above) — it's a single, one-size-fits-all structural optimization with no quality trade-off to tune, for better or worse.
What to Actually Do With a Scanned PDF That's Too Big Today
Given that our compressor doesn't recompress images yet, the practical path for a genuinely oversized scanned document is to control image quality before it becomes a PDF: scan at a lower DPI or "web quality" setting if you control the scanning step, or run each page through Image Compressor and rebuild with Image to PDF if you're starting from a PDF that's already too heavy. Running Compress PDF afterward is still worth doing — it's free, lossless, and reduces structural overhead — but treat it as a small final pass, not the step that gets you from 8MB to 1MB.
The Bottom Line
A PDF compressor isn't magic, and "PDF compressor" doesn't mean one specific technique — it can mean real, lossy image recompression, or a lossless structural repack that leaves images untouched, and the two produce wildly different results on the same scanned file. Understanding whether your PDF is text-heavy or image-heavy, and which of the two approaches the specific tool you're using actually implements, sets realistic expectations before you rely on any compressor for a size target that matters.