Choosing the right compression level

Compression settings look like a straight trade between size and quality. In practice the right setting depends almost entirely on where the document is going to end up.

For something that will be printed

Use the lightest setting, or do not compress at all. Print is unforgiving: artefacts that are invisible on a screen at one hundred per cent zoom become obvious on paper, particularly around text edges and in large flat areas of colour. If a document is going to a printer, the file size almost never matters as much as the output.

For something that will be read on screen

Balanced settings are usually indistinguishable from the original at normal reading zoom. Most screen reading happens at an effective resolution well below print, so the extra data is genuinely unused.

For something that only needs to be legible

Strong settings soften text noticeably. That is fine for a receipt attached to an expense claim, a proof of address, or a scanned form going into a records system where a human will glance at it once. It is not fine for anything anyone will read closely.

The case where none of them help

A document made of real text, one where you can select the words, has almost nothing for an image compressor to remove. Every browser-based compression tool, including this one, works by rendering pages and re-encoding them as images. On a text document that produces a bigger file than you started with, and the text stops being selectable.

This is worth stating plainly because a lot of tools do not: if a compressor cannot make your file smaller, the honest result is to tell you so and hand back the original.

A practical order of operations

Try removing metadata and flattening forms first, since both are lossless. If the file is still too big, check whether it is a scan. If it is, compress. If it is not, the size is coming from somewhere compression cannot reach, usually revision history or embedded fonts, and the right fix is a different one.

What the settings are actually doing

Every browser-based compressor works the same way: render each page to an image, then encode that image at a chosen resolution and quality. The level you pick sets two numbers, and both matter.

Resolution decides how much detail survives. Halving it removes three-quarters of the pixels, which is a large saving and invisible on screen until you zoom.

Quality decides how aggressively the encoder discards information within the pixels that remain. This is where artefacts come from: soft haloes around dark text, blockiness in flat areas, and a slight muddiness in photographs.

Resolution is the safer lever. Dropping resolution produces a smaller, cleaner image; dropping quality too far produces an image the same size in pixels that simply looks worse.

Judging the result properly

Look at the output at 100 per cent zoom, not fitted to the window. Fitting a page to a small window hides exactly the artefacts you are checking for.

Look at the smallest text on the page and at any thin lines or table rules. Those degrade first. Photographs tolerate compression far better than text does, which is why a document of pictures compresses beautifully and a document of footnotes does not.

When to stop

There is a point where each further step down saves very little and costs a lot of legibility. On most scans it arrives sooner than people expect.

If a document is still too large at a setting where the text has gone soft, compression is the wrong tool. Split it into parts, or send a link instead. Making a document illegible to fit an arbitrary limit serves nobody.

Keep the original

Every compression is one-way. The discarded detail is gone, and running the file through again only degrades it further.

Keep the source. If someone comes back needing a print-quality version, you will want it, and there is no route back from the compressed copy.

Testing on one page first

On a long document, compress a two- or three-page extract before committing to the whole thing. It takes seconds and tells you whether the setting is right at a scale where you will actually look at the result.

Compressing sixty pages, discovering the text has gone soft, and starting again is the common way this wastes an afternoon.

Greyscale as a separate lever

Removing colour from a document that has none worth keeping typically saves a further ten to twenty per cent, and it is orthogonal to the quality setting.

For scans of black ink on white paper this is nearly free: the colour information in the file is sensor noise rather than content. For anything where colour carries meaning. A highlighted passage, a chart, a signature in blue ink to prove it is not a photocopy, leave it alone.

What to tell someone who asks for "the smallest possible file"

Ask what it is for. The honest answer is nearly always different from the question.

If it is an email limit, the target is a number, and there is usually a setting that reaches it without visible damage. If it is storage, compression is rarely the right lever and archiving policy is. If it is "the website only accepts 2 MB", check whether splitting is acceptable, because a legible document in two parts beats an illegible one in one.