How to make a PDF smaller — and keep it readable

The short answer

Re-encode the images. In almost every oversized PDF the images are the file, and reducing their resolution to what the page actually displays — around 150 DPI for screen reading, 300 for print — together with a JPEG quality around 80% removes most of the excess without a visible difference.

What matters more than the numbers is which of two very different operations your tool is performing, because one of them quietly destroys your document.

Two methods that get the same name

"Compress PDF" describes two things that behave nothing alike.

The first re-encodes the embedded images in place. It downsamples anything stored at more resolution than the page uses, re-compresses it at a lower quality, and leaves everything else alone. Your text stays text — selectable, searchable, readable by a screen reader — and the document simply gets smaller.

The second renders every page to a bitmap and rebuilds the document from those pictures. It compresses harder, and it converts your text into a photograph of text. Search stops working, copy-and-paste stops working, accessibility stops working. For a scan that costs nothing, because the pages were already images. For a contract it is a serious loss, and tools that do it rarely say so.

There is a one-second test on the output: try to select a line of text. If you cannot, the tool rasterised your document.

How much quality loss is actually visible

This is the part most compression tools do not explain, and it is the difference between a PDF that looks fine and one that looks smudged.

For anything read on a screen, 150 DPI is around the practical ceiling of what the eye distinguishes from 300 DPI at normal reading distance. For print, 300 DPI is the standard target; below that it starts to show at the edges of text and in fine lines.

On JPEG quality, the range between 100% and roughly 80% is where compression does the most work for the least visible cost. Most of the size reduction happens early, while the artefacts people notice — blockiness around sharp edges, banding across smooth gradients — do not appear until well below that.

So: 150 DPI and 80% quality for a document destined for a screen, higher on both for anything printed or containing line art, architectural drawings or small type.

How far you can realistically expect to get

Worth setting expectations, because the honest range is wide and depends entirely on what the file is made of.

• A colour scan at 600 DPI — routinely 80–95% smaller, with no visible difference on screen. This is the case compression was designed for.
• A report with embedded photographs — typically 50–80%, depending on how many and how oversized they were.
• A design-tool export at print resolution — often 60–90%, since it was optimised for a press rather than a screen.
• A text-only document — 0–10%, and that is the correct answer rather than a failure. There is no slack to remove. If a 2MB text report will not shrink, it was already efficient.

When compression is the wrong tool

If the file is already made of efficiently compressed images, another pass buys very little — there is not much left to remove, and pushing harder only degrades what is there.

If the document is long rather than heavy — three hundred pages of real text — splitting it is more honest than compressing it. Compression has almost nothing to work on, so you would trade quality for a saving that was never available.

And if the real complaint is that a stack of scans is unwieldy rather than merely large, the answer is a text layer, not smaller images. Optical character recognition makes the file searchable, which addresses the actual problem in a way that shrinking the pictures never will.

Frequently asked questions