How to compress a PDF

Downsampling changes how many pixels an image has. An image placed in a 4-inch-wide slot on the page at 600 DPI carries 2400 pixels across; capping it at 150 DPI resamples it to 600 pixels, and the discarded pixels are gone. This is the lever that matters when a phone photo was dropped into a document at full sensor resolution.

JPEG quality changes how precisely the pixels that remain are described. At a lower quality setting the encoder is permitted to be more approximate within each block of the image, which shows up as blocking in smooth gradients and as halos around the hard edges of text inside a screenshot.

Because they act on different things, they fail differently. A high-resolution image at low JPEG quality is sharp but mottled. A heavily downsampled image at high JPEG quality is clean but blurry. Diagnose which of the two you are seeing before you reach for a slider, or you will turn the wrong knob.

A scanned document that only needs to be readable on screen tolerates aggressive treatment: a low DPI ceiling, lower JPEG quality, and grayscale if the scan was of black ink on white paper. Colour channels in that case are recording paper tint and scanner noise, not information.

A document with screenshots is the fussiest case, because screenshots contain text rendered as pixels. Text edges are exactly what JPEG handles worst, so keep quality higher than you would for photographs and let DPI do more of the work.

Anything heading for print should keep a 220 or 300 DPI ceiling and high JPEG quality — the saving comes from stripping metadata and de-duplicating resources rather than from touching the images. And a document that will be re-compressed later should be left alone now: JPEG loss accumulates with each generation, and re-encoding an already-compressed image degrades it further while saving very little.

Text in a PDF is a set of glyph-drawing instructions referencing an embedded font, and those instructions are already stored in a compressed stream. There is no large redundant payload to squeeze, and the image levers have nothing to act on because there are no images.

A 200-page contract that is 400 KB is 400 KB because that is roughly what the glyph runs and the font subsets weigh. Running compression on it may save a few percent from metadata removal and stream tidying, and anyone promising a dramatic reduction on such a file is describing a document that was mostly images to begin with.

The exception worth knowing: a file that embeds full fonts rather than subsets, or embeds the same font several times, carries real redundancy. That saving is lossless and comes from resource handling, not from quality reduction.

Document information and XMP packets hold the title, author, producing application, creation and modification timestamps, and whatever else a generating tool wrote in. Removing them changes no pixel and no glyph, so it is safe in a way that the image levers are not.

The size saving is usually small — kilobytes, occasionally more when an application wrote a large XMP block. The reason to do it is more often privacy than size: author names, internal file paths and software versions travel in those fields and are visible to anyone who opens the document properties.

What it does not do is remove anything from the page. Text that appears in the document body, including a name in a footer, is page content and is unaffected by metadata removal.