How to compress a PDF file

Before compressing anything it is worth knowing what you are compressing. A text-only PDF of forty pages is often under 300 KB, because the text is a few thousand glyph instructions and a font subset. A twelve-page scanned contract can be 17 MB. The difference is not the page count and it is not the text — it is the images. In practice, when someone says a PDF is too big, well over ninety per cent of the bytes are pictures, and the entire job of a compressor is to re-encode those pictures at a size that still looks right on screen. Everything else — stripping metadata, cleaning up unused objects, rewriting the cross-reference table — moves kilobytes, not megabytes.

Two knobs, and only two

Image compression comes down to resolution and quality. Resolution is how many pixels the image contains; a scanner producing 300 dots per inch generates roughly four times the pixels of a 150 dpi scan of the same page, and pixels are bytes. Quality is the JPEG setting applied afterwards, on a scale where 1.0 keeps almost everything and 0.4 begins to show visible artefacts in flat areas. Our three presets pair the two: light caps the long edge at 1700 pixels at quality 0.80, balanced at 1240 pixels and 0.62, aggressive at 1000 pixels and 0.45. Balanced is the one that suits most documents, because a page rendered 1240 pixels tall is still sharper than the screen most people read it on, and because the drop from 0.80 to 0.62 removes a surprising fraction of the bytes without touching legibility of body text.

The numbers we measured

These are real files run through the tool, not estimates. A twelve-page scanned document, the kind a lawyer or an accountant sends by email, went from 17.69 MB to 1.49 MB on the balanced preset — a 91.6 per cent reduction. A seven-page slide deck exported to PDF went from 6.55 MB to 1.87 MB, 71.5 per cent. The gap between the two is instructive: the scan is nothing but photographs of paper, so re-encoding them dominates; the deck contains vector shapes and text that compression cannot touch, so its ceiling is lower. Whatever tool you use, expect the biggest wins on scans and photo-heavy files, and modest ones on documents that were born digital.

Formats matter more than settings

There is a trap that costs many tools their result: browsers and office suites frequently embed images as Flate — a lossless format — rather than as JPEG. A compressor that only knows how to handle embedded JPEGs sees those images, does not recognise them, and skips them. On our first attempt at that 17.69 MB scan the result was a 0.0 per cent saving after seventy seconds of work, because all twenty-four images were Flate-encoded and every one was skipped. Decoding them to raw pixels first and re-encoding as JPEG is what turned 0 per cent into 91.6 per cent. If a compressor tells you a visibly image-heavy file cannot be improved, this is very often the reason.

When a PDF genuinely cannot shrink

Some files are already optimised, and an honest tool says so instead of producing a slightly different file of the same size. A PDF that is mostly vector text has almost nothing to give. Worse, structural rewriting can make a small file bigger: running a linearising optimiser over a lightweight document added seventy-one per cent to it in our tests, because the added cross-reference structures outweighed the savings. The rule we settled on is to keep whichever file is smaller — source or result — and to report "already optimised" rather than claim a win when the gain is under about three per cent. If a tool always shows you a saving, be suspicious of what it is measuring.

Transparency, masks and the images tools skip

There is a category of image that compressors treat nervously: pictures with transparency. In a PDF, a soft transparency mask is stored as a separate greyscale object referenced by the main image, and a cautious compressor skips anything carrying one rather than risk a black box where a logo used to be. That caution is expensive. In our own testing the single largest image in a real document — 2.58 MB of it — was being skipped for exactly this reason, so the file kept 2.58 MB it did not need. The correct handling is narrower than the blanket rule: because the mask is an independent object, the base image can be re-encoded as JPEG and the mask reference simply left in place, and transparency survives untouched. Only two cases genuinely must be left alone: stencil masks, which are one-bit-per-pixel shapes with no tonal information to compress, and explicit colour-key masks, where specific colour values are what make pixels invisible and re-encoding would shift them. Similarly, a colour-inversion instruction attached to an image belongs to its old encoding and must never be copied onto the new one, or the picture comes back as a negative. These are unglamorous details, but they are the difference between a compressor that quietly gives up on your biggest images and one that actually finishes the job.

A practical order of operations

Try balanced first and look at the result at 100 per cent zoom, not at the thumbnail. Check the smallest text on the busiest page — a footnote, a stamp, a signature block — because that is where quality loss appears first. If it holds up and you still need to be smaller, step to aggressive; if it does not, step to light and accept a larger file. Only if the file is still too big should you consider splitting it, since three attachments of 4 MB are usually easier to send than one of 12 MB. And if your source is a scanner you control, the cheapest fix of all is upstream: scan at 200 or 300 dpi in greyscale rather than 600 dpi in colour, and the problem never arises.