Why compressing a PDF is harder than compressing a photo

Technical 10 September 2026

A photo is one thing. A PDF page is several things pretending to be one

A JPEG photo is a single grid of pixels, and JPEG compression is very good at throwing away the specific kind of detail a human eye barely registers in a photograph — subtle color gradients, fine texture — while keeping the parts that matter. That is why you can compress a vacation photo to a fraction of its size and not notice much difference.

A PDF page is not one thing. It can simultaneously contain vector text (each letter described as a precise mathematical outline, not a grid of pixels), embedded images, vector line art, and font data, all layered on top of each other. There is no single compression technique that is the right tool for all of that at once. Compressing the text the way you would a photo means rasterizing it — turning sharp vector letterforms into a grid of pixels — which is a fundamentally different, lossier operation than shrinking a photo, because it is throwing away information that was exact to begin with, not information the eye wasn't using.

Where the size in a PDF actually comes from

For a document that started life as a scan or a photographed page, nearly all of the file size is the images. A page shot on a phone at full resolution can easily be several megabytes, and ten such pages add up fast. This case compresses well, because there is real, meaningful redundancy in a high-resolution photo of a mostly-white page that downsampling and JPEG-style compression can remove with limited practical cost — the text was already a picture of text, not real text, so making that picture smaller loses nothing that wasn't already lost when it was scanned.

For a document exported directly from a word processor or design tool, the size is mostly vector text and font data, which is already extremely compact — a hundred pages of real text might be a few hundred kilobytes. There often isn't much left to compress without converting that efficient vector text into inefficient pixel images, which makes the file larger for the same visual quality, not smaller, and is exactly the case where a compression tool should say so rather than compress anyway.

The trade-off that most tools don't explain

Once a page has been rasterized to shrink it, the text on that page is a picture of text. It can no longer be selected, searched, or read aloud, and it will not respond to the system font size a screen reader or magnifier relies on. For a scanned document, this is usually not a real loss — the text was already just an image before compression touched it. For a document that started as real, selectable text, compressing it this way is a one-way trip: character rasterizes are not reversible, and there's no way to get the original selectable, searchable text back afterward.

This is why a compression tool that just reports a smaller file size without saying anything about this trade-off is leaving out the part that actually matters for deciding whether to use it.

What actually helps, beyond just picking a lower quality setting

Knowing which case a document falls into before compressing matters more than the quality slider does. If a file is already a scan, rasterizing it further costs nothing that wasn't already lost, and a lower quality setting is close to free. If a file has real, selectable text, check whether the source program — Word, Google Docs, whatever produced it originally — can export a smaller PDF directly, since that avoids the trade-off altogether rather than making it and hoping it doesn't matter.