Why "compress PDF without losing quality" is usually only half true

Search for a PDF compressor and nearly every result promises the same thing: smaller file, no quality loss. Several of those same tools then offer you a choice of compression strength.

Both statements can't be fully true at once. Stronger compression means more information discarded. If nothing were discarded, the setting would do nothing.

This isn't a scandal, and the tools aren't useless. But the framing hides the one decision that actually matters, which is what you're willing to give up.

Lossless compression repacks what's already in the file. Object streams get restructured, duplicate resources get merged, unused entries get dropped. Every byte of original content survives. Nothing visible changes.

It also barely shrinks anything. One of the more candid tools in this category says so outright on its own compression page: lossless mode is available, and you shouldn't expect much size reduction from it.

Lossy compression re-encodes the images inside the document at lower resolution or lower JPEG quality. This is where the dramatic 80% reductions come from. It works because photographs tolerate a surprising amount of degradation before most people notice.

When a tool advertises a big reduction and also claims no quality loss, it is almost always doing the second thing and betting you won't zoom in.

Your PDF is probably big because of images

This is the part that makes the rest make sense.

Text in a PDF is stored compactly to begin with. A long text-only document is often a few hundred kilobytes. A single high-resolution photograph dropped into a page can be several megabytes on its own — easily the large majority of the file.

Two consequences follow:

Image-heavy documents and scans compress well — often dramatically.

Mostly-text documents are different: compression will barely help, and any tool that returns a dramatically smaller file has done something more aggressive than repacking. Worth checking what.

Before compressing anything, it's worth knowing which of those two you have. Checking the page setup tells you the page dimensions and whether they're consistent — unusually large page sizes are a common and easily-fixed cause of bloat that no compressor will diagnose for you.

The failure mode nobody advertises

There's a specific way browser-based compression goes wrong, and it's worth recognising because the output looks fine at a glance.

The approach is to render each page to a canvas, re-encode that canvas as a JPEG, and build a new PDF from those images. It's the only route available to a browser-only tool, because the JavaScript PDF libraries can't re-encode the image streams inside an existing document.

On a scan, this is reasonable — the pages were already images.

On a text document, it's destructive. Your text stops being text and becomes a picture of text. You lose the ability to search it, select it, or copy from it, and a screen reader can no longer read it at all. For many text PDFs the result is also larger than the original, because a photograph of a page of text is bigger than the text itself.

A compressed PDF that comes back with unselectable text has been through exactly this.

Why there's no Compress tool here

We've looked at building one several times and haven't shipped it.

The browser-only approach would mean quietly destroying the text layer on exactly the documents people most want to compress. Doing it properly means server-side processing, which would break the thing that makes this site worth using: everything except Word to PDF stays in your browser, as we set out in what browser-based tools cannot do.

We'd rather not have the tool than have one whose button we couldn't describe accurately.

What to do instead

Depending on why the file is too big:

Compress the images before they go in. Resize photographs first, while you're still building the document. A 4000-pixel-wide image on a page that displays it at 600 pixels carries roughly 40 times more data than it needs. If you're assembling a PDF from pictures, shrink them before converting rather than after.

Split it. If the problem is an email attachment limit, splitting the PDF into parts sends the whole thing without degrading anything. Two 6 MB files clear a 10 MB limit that one 12 MB file doesn't.

Remove what isn't needed. Deleting pages you don't need to send is the only fully lossless size reduction there is, and it's usually overlooked.

Check for the obvious. Oversized page dimensions, a scan captured at 1200 DPI when 300 would do, the same logo embedded fifty times. Page size and the metadata editor will show you some of this before you reach for a compressor.

Use a proper tool when you need real lossy compression. Ghostscript, or Acrobat's own optimiser, will do it better than any browser can. For a sensitive document, run it locally rather than uploading — the same reasoning behind our tool-by-tool privacy breakdown.

The question worth asking

Before you compress: is this file large because of images, or is it just large?

If it's text, no compressor is going to help much, and one that appears to has probably changed something you'll miss later. If it's images, then the real question is how much quality you're prepared to lose — which is a decision, not a setting you can leave on the default and forget about.

Neither answer is served well by a button that promises both.

To work out what your file is carrying first, the page size checker and the metadata editor both run in your browser and take about a minute each. The full toolset is here if you need something else.