Skip to content
2xKit

How PDF Compression Actually Works (And Why Some PDFs Won't Shrink Much)

What's really happening when a PDF gets smaller, and why a scanned contract compresses differently than a photo-heavy brochure.

Quick answer

PDF compression mainly re-encodes embedded images at a lower resolution or higher JPEG compression, strips unused fonts and duplicate objects, and removes redundant data structures; it rarely shrinks a PDF that's already mostly text, since text streams are small to begin with. Run a file through the Compress PDF tool to see how much headroom it actually has before assuming it can't get smaller.

A PDF isn't one uniform blob of data, it's a container holding several very different kinds of content: text streams, embedded fonts, vector graphics, and raster images, each stored and compressed differently. When a compression tool shrinks a file, it's really targeting whichever of those components is taking up the most space, which is why the same tool can shave 90% off one file and barely touch another.

Where the size actually comes from

In most everyday PDFs, embedded images are the dominant cost by far. A single high-resolution scanned page can be several megabytes on its own, while a page of pure text, even a dense one, is typically a few kilobytes, because text is stored as compact character codes plus a font reference rather than pixel data. That's the core reason a 40-page scanned contract can be larger than a 400-page text-only report.

Compression tools exploit this by downsampling images (reducing their pixel dimensions to match realistic print or screen resolution) and re-compressing them with a lossy codec like JPEG at a higher compression ratio. Fonts get subsetted, meaning only the specific characters actually used in the document are kept instead of the entire font file, and duplicate objects, like the same image referenced on multiple pages, get de-duplicated instead of stored repeatedly.

Why some PDFs barely shrink

A PDF that's already mostly compact text and vector graphics, like a spreadsheet export or a simple invoice, has very little to compress further, most of its bytes are already efficiently encoded. Similarly, a PDF built from images that were already heavily compressed before being embedded won't shrink much on a second pass, since re-compressing an already-lossy JPEG mostly just adds more visible artifacts without meaningfully reducing size.

This is also why scanned documents behave differently from born-digital ones. A page scanned at 600 DPI in full color contains far more pixel data than the same page would need for on-screen reading, so it has a lot of genuine headroom to compress. Running it through Compress PDF with a moderate quality setting typically cuts scanned files down dramatically, while the same tool applied to a text-heavy report might only save a few percent.

Getting a smaller file without wrecking quality

If a compressed PDF still needs to look sharp (a portfolio, a printed brochure), it helps to compress before adding heavy elements rather than after: run Compress PDF on source images first, or compress the assembled PDF at a moderate rather than maximum setting and check a few pages at actual size before sending it anywhere. Converting a color scan to grayscale with the PDF Grayscale Converter is also worth trying first when a document doesn't need color at all, since dropping the color channels entirely reduces image data more predictably than lossy re-compression does.

Frequently asked questions