How PDF Compression Actually Works, and How to Shrink a File Without Wrecking It

Almost everyone has hit the wall where an email refuses to send because the attachment is too big, or a web form rejects a document for being over some invisible limit. The reflex is to search for a way to “make the PDF smaller” and hope for the best. The results are unpredictable because compression is not one thing. It is a handful of very different operations that happen to share a button.

If you understand where the weight in a PDF actually comes from, you can shrink a file on purpose instead of by luck, and you can tell in advance whether the result will still look good.

Where the megabytes actually live

A PDF is a container. Inside it are usually four kinds of things, and only some of them are heavy:

• Images. A single full-page scan can be several megabytes. Ten scanned pages can be a thirty-megabyte file on their own.
• Fonts. Embedded fonts add weight, but they are small compared to images and you rarely want to remove them.
• Vector graphics and text. Real text is astonishingly light. A hundred pages of pure text is often under a megabyte.
• Overhead. Duplicated objects, revision history, and uncompressed internal streams that never got cleaned up.

The practical takeaway is blunt: if your PDF is large, it is almost always because of images, and specifically because of scans. Text-heavy documents are already small. So “compressing a PDF” usually means “compressing the pictures inside it,” and everything else is a rounding error.

The two kinds of compression, and why it matters

There are two families of compression, and confusing them is why people get bad results.

Lossless compression reorganises the file without throwing anything away. It deduplicates repeated objects, compresses internal streams, and strips leftover junk. The document is byte-for-byte identical to read; it just takes less space. This is always safe. The catch is that it only recovers modest amounts on a file that is mostly images.

Lossy compression actually discards detail. For images that means lowering resolution and increasing JPEG compression. This is where the real savings live, and also where quality goes to die if you overdo it. Push it too far and sharp black text on a scan turns into a grey smear surrounded by blocky artefacts.

Most tools do both at once and hide the distinction. That is fine, as long as you know that the size you save beyond the first pass is coming out of your image quality.

A recipe that works

Here is the order of operations we actually use.

Start with the direct route: run the file through Compress PDF and look at the result before anything else. For a lot of documents that single step is enough, and because it happens in your browser, the file never leaves your device.

If the file is a merged bundle of several documents, compress it as one job rather than piece by piece. If you still need to assemble it, use Merge PDF first and then compress the combined result, so the tool can deduplicate shared resources across the whole thing.

If the heavy part is scanned pages, the highest-leverage move is to reduce the scan resolution. A document meant to be read on a screen almost never needs more than 150 dots per inch; anything above that is invisible to the reader and expensive in bytes. When the pages are photographs of text, running OCR first often helps twice over: it makes the document searchable, and the recognised text layer can replace some of the raw image weight.

If you are the one creating the PDF from images, shrink the images before you ever build the file. Pushing your source pictures through the Image Compressor or resizing oversized photos with the Image Resizer means the PDF starts small instead of being fixed after the fact.

How small is too small

A good rule: compress to the job, not to a number. A contract you are emailing for signature needs to be legible, not archival. A portfolio going on the web should look crisp on a high-resolution screen. A document destined for a professional printer should barely be compressed at all, because print needs the resolution that screens throw away.

If you cannot read the smallest text on your phone at full zoom, you have gone too far. Back off one step. The difference between a two-megabyte file and a one-megabyte file is rarely worth illegible fine print.

When not to compress at all

Skip compression for anything you are keeping as a permanent record, anything going to print, and anything legal where the exact reproduction matters. Storage is cheap; a re-scanned contract is not. Compression is a delivery optimisation, not a filing strategy. Shrink the copy you send, keep the original you trust.

Why the same file comes out a different size everywhere

If you run one document through several compressors, you will get several different sizes, and it is tempting to just pick the smallest. Resist that. A tool that produces a dramatically smaller file has usually made a more aggressive quality decision on your behalf, downsampling images harder than the others. The smallest number is not the winner; the smallest number that still looks right is. Always judge the result by opening it, not by comparing file sizes in a folder.

There is a second trap: generation loss. Every time you compress an already-compressed image, you throw away a little more, and the artefacts accumulate. Compressing a PDF, decompressing it, editing it, and compressing it again is how a once-crisp document slowly turns muddy over months. Compress once, at the end, from the best original you have, and keep that original untouched so you always have a clean starting point to go back to.

Understand the file, shrink the images, and check the smallest text. That is the entire craft, and it will save you from ever again emailing a document that bounces or arrives unreadable.