How to Compress a PDF (and When Not To)

A few months ago I watched someone try to email a 47 MB PDF by "compressing" it six times in a row with different tools. The file ended up at 43 MB and looked worse. The recipient, it turned out, had a 50 MB attachment limit anyway. The whole exercise was unnecessary.

Compression is one of those things where a small amount of understanding saves a lot of frustration. So here's the honest version.

What compression actually does

A PDF contains several kinds of things: text (encoded as character codes plus font references), images (usually JPEG or PNG streams), vector drawings (line and shape commands), and metadata.

Compression reduces size by attacking one or more of these:

• Re-encoding images at lower quality — this is the biggest lever. A JPEG at quality 90 takes about four times the space of the same JPEG at quality 50.
• Downsampling image resolution — a 300 DPI image displayed at 72 DPI in the PDF wastes pixels. Downsampling to 150 DPI halves size without visible quality loss on screen.
• Recompressing text streams — PDFs already use Flate (zlib) compression on text. Some tools try harder.
• Deduplicating resources — the same font embedded twice becomes one copy.
• Removing metadata and unused objects — a small win, maybe 1-5%.

What compression cannot do: make a 100-page document small enough for a 5 MB email attachment without visible degradation. Physics wins.

The two types of compression

There are two fundamentally different approaches, and most tools don't tell you which one they use.

Approach 1: Image re-encoding (good)

The tool identifies embedded images, decodes them, re-encodes them at a lower quality or resolution, and replaces them in the PDF. Text remains text — searchable, selectable, sharp at any zoom.

This is what dedicated tools like Ghostscript do, and what most desktop compression tools do. It's the correct approach. It preserves document fidelity where it matters and only trades quality in the regions where quality was already JPEG-compressed anyway.

Approach 2: Page rasterization (lossy)

The tool renders each page to a JPEG image, then rebuilds a PDF where each page is just that image. Text is no longer text — it's pixels. You can no longer search, select, or copy it.

This is the approach used by many browser-based tools, including ours, because re-encoding embedded images is much harder in JavaScript. To do it properly you have to parse the PDF's internal object structure, decode every image stream, re-encode, and rewrite the object references — all without breaking the file.

The trade-offs are substantial:

Our Compress PDF tool uses page rasterization, and says so explicitly on the tool page. If you need searchable text after compressing, our OCR PDF tool can rebuild a text layer — but it will be approximate, not the original text.

Realistic size expectations

Here's a rough guide, based on real files we've seen.

Notice the last row. Re-compressing an already-compressed file rarely helps. We've seen people run the same file through three different tools hoping for a different result. The tools all use similar algorithms; they'll all produce similar output.

The "compress to 100 KB" myth

Some websites advertise "compress PDF to 100 KB" as if it's a service they can guarantee. Here's what actually happens: they run the same rasterization, and if the result isn't under 100 KB, they either lie about the output size, or they crank quality down to 5% and produce something unreadable.

Our approach is different: we offer a target-size mode, but if the target is unreachable without destroying the document, we tell you the best result we achieved and let you decide. No fake success.

When NOT to compress

Compression isn't always the right move. Skip it when:

• The file needs to be searchable. Rasterization kills text search. If your recipient will Ctrl+F, don't rasterize.
• The document is a contract or legal record. Any alteration to the file content can be questioned. Keep the original bytes.
• The file is under 5 MB. It's almost certainly fine to send as-is. Most email services handle 25 MB.
• You'll need to edit it later. Text in a compressed PDF is images. Editing requires rebuilding the document from scratch.
• Archival copies. Compression is lossy by definition. Keep the original uncompressed version for archives.

The practical workflow

Here's what I actually do when someone sends me an oversized PDF:

Step 1: Check what's actually in the file

Open the PDF and look at a few pages. Is it mostly scanned images? Mostly text? A mix? If it's mostly images, compression will help a lot. If it's mostly text, you probably can't compress much.

Step 2: Ask whether compression is needed

This sounds obvious, but: does your email client actually reject the file? Most accept up to 25 MB. Google Drive, Dropbox, and WeTransfer handle anything bigger. Sometimes a share link is better than a smaller file.

Step 3: If you must compress, compress once

Run it through once with a moderate quality setting (say 70%). Check the result. If it's good enough, stop. If not, try once more at a lower quality. Then stop.

Running the output through again rarely helps because the tool is re-compressing an already-compressed file — same algorithm, diminishing returns.

Step 4: Verify before sending

Open the compressed PDF. Check that:

• All pages are present
• Text is readable (or at least legible)
• Charts and images are recognisable
• Nothing important got cut off

It's worth the thirty seconds. We've seen people send compressed documents where signatures became illegible blobs.

FAQ