How to compress a PDF without losing readability

How to compress a PDF without losing legibility

The intake form says forty megabytes and your file is fifty-two. Compression solves that in a minute, but it has settings, and the defaults are not the obvious ones.

It helps to understand up front where the weight actually goes. Text in a PDF weighs almost nothing. What makes a document heavy is images: scans, photos, screenshots, logos left at their original resolution. So compression works mostly on images, and on a contract made of plain text it will not do much.

The compression level and the profile that overrides it

There are three levels, and the strongest one is the default.

Next to it sits a second setting, the processing profile, and this one behaves unexpectedly. There are three profiles too: fast, balanced and quality. Balanced is the default.

The surprise is that the quality profile does not merely process more carefully, it drops the chosen compression level by one step. So a high level combined with the quality profile actually behaves like medium. That is not a bug but a deliberate guard against asking for maximum compression and maximum quality at the same time.

The fast profile works differently: it skips the main processing pass. The file is ready noticeably sooner, but it also shrinks less. For an urgent send that is a reasonable trade; for an archive it is not.

Target DPI

The target resolution for images inside the document is set separately, from 72 to 600, defaulting to 150.

That is the resolution images will be resampled to. A hundred and fifty to two hundred counts as the working range for documents read on screen: text in a scan stays legible while the weight falls several times over. Below a hundred, small type starts to fall apart.

There is a catch in how the settings interact. Target DPI is applied in the main processing pass, and the fast profile skips that pass. So with the fast profile the DPI you set simply will not take effect, unless image optimisation is switched on, since that resamples images independently.

Image optimisation is off by default

This setting re-encodes embedded images and yields extra savings wherever pictures were stored inefficiently.

It is off by default for a reason: re-encoding changes the pixels themselves. For a document headed into an authenticity check, a court or an expert examination, that may be unacceptable. If image fidelity matters, leave it off.

In every other case it is worth switching on. On a batch of scans it usually delivers the most noticeable gain, because scanners and phones save images with plenty of headroom.

Step by step

1. Open compress-pdf and upload the document. 2. Leave the level on high unless you know you need a gentle pass. 3. Do not set a high level and the quality profile together: they cancel each other out. 4. For scans, switch image optimisation on. 5. Download the result and open the busiest page rather than the first: the one with small type, a stamp or a table.

Step five matters more than it looks. A title page almost always survives compression well; what falls apart is usually the small caption under a table on page eight.

Why the result is never heavier than the source

This is engineered deliberately, and knowing it is useful.

Compression does not make a single pass. It tries several processing variants and at the end compares them against each other and against the original file. The smallest of them all is what you get. If no variant came out lighter than the original, the original wins.

A practical conclusion follows: trying compression risks nothing. The worst that happens is your own file coming back with an honest message. The "I compressed it and it got bigger" situation cannot occur here by construction.

The same fact means there is little point cycling through settings hoping for a miracle. If a high level with image optimisation on produced nothing, a low level certainly will not: the service already tried the variants within one run. What needs changing is not the settings but the approach, meaning less content.

Several files in one go

You can compress a batch of documents at once, and the settings apply to all of them equally. That suits a uniform set: ten scans of the same kind get handled in one move.

The output is an archive whose files carry your original names with a `compressed_` prefix. If two uploaded files shared a name, numbers are appended so nothing gets overwritten.

The report on the result is not a lump sum, though: the service names the individual files it could not shrink. That matters for a batch, because the total archive weight can fall thanks to the successful files and hide the one stubborn document that still misses the limit.

If the set is mixed, split it into groups. Text and scans need different settings: on the first, image optimisation is pointless; on the second it delivers the entire gain.

One more way to shed weight: drop the colour

If compression squeezed out all it could and the file is still heavy, there is a trick people forget.

A colour scan of a black-and-white document stores colour that is not really there: the greyish tint of the paper, the yellow of the lamp, the bluish shadow of a fold. All of it takes up space alongside the meaningful data. Converting to greyscale with pdf-to-grayscale removes that ballast entirely, and on a batch of scans the gain is usually larger than from compression itself.

There are three greyscale profiles, and the default is the standard one, safe for mixed office documents. Caution is due where colour carries meaning: a blue stamp, a coloured signature, a line picked out in highlighter. After conversion they stay legible but stop being coloured, and if the receiving side expects colour, this route does not suit.

Order matters here: greyscale first, compression second. The reverse works worse, because compression will spend effort on colour data you were going to throw away anyway.

What is pointless to compress

A document made of text and tables shrinks by a few per cent. Expecting a meaningful win there is unrealistic, and if such a file misses the weight limit, the cause is probably the page count rather than the pictures.

A separate case is a file that has already been compressed. A second pass barely reduces the weight while quality drops a second time, because the artefacts of the previous pass compound with the new ones. If the result disappointed, go back to the source and compress it once with different settings rather than running the finished file through again.

A scan made at low quality to begin with has little left to compress: there is not much data in it. Such a document is easier to reshoot than to optimise.