The Complete Guide to PDF Compression

Almost everyone meets PDF compression the same way: a form refuses a 14 MB upload, an email bounces at a 10 MB attachment limit, or a portal insists on "under 2 MB" for a document that is plainly under 2 MB worth of information. The instinct is to look for a button that makes the number smaller. The more useful question — and the one that determines whether you can hit the target at all without wrecking the document — is which bytes in this file are actually large, and what would it cost to remove them.

This guide answers that. It covers what a PDF is made of, which parts compress losslessly and which do not, where the real savings live, and how to reduce PDF file size at the source rather than fighting it afterwards.

One thing up front, stated plainly: this site does not have a PDF compression tool. Our PDF tooling is a PDF Merger that combines documents in your browser without uploading them, and it deliberately does not re-encode anything. What this guide gives you is the working knowledge to shrink documents properly, plus a genuinely effective workaround for image-heavy PDFs that uses tools we do have. We would rather tell you how the format works than sell you a button.

A PDF Is a Container, Not an Image

The single most common misconception is that a PDF is a picture of a document. It is not. A PDF is a structured collection of numbered objects, each of which may hold a different kind of data compressed in a different way.

A typical file contains:

• Content streams — the drawing instructions for each page. "Move to this coordinate, set this font at 11 points, show this string, stroke this path." These are text-like and compress extremely well with Flate (the same algorithm behind ZIP and PNG).
• Font programs — actual TrueType or CFF font files embedded so the document renders identically everywhere.
• Image XObjects — every photo, logo, chart screenshot, and scanned page, stored as raster data with its own encoding: DCTDecode for JPEG, FlateDecode for lossless, JBIG2 or CCITT for bilevel scans.
• Metadata, structure, and navigation — the cross-reference table, bookmarks, form fields, annotations, embedded colour profiles.

Compression is applied per stream, not to the file as a whole. This is why zipping a PDF barely helps: the compressible parts were already compressed when the file was written. It is also why "compress this PDF" is an ambiguous instruction until you know which of those categories is dominating your byte count.

For nearly every oversized PDF in the wild, the answer is the third one. Images are usually 80-95% of a large file. Everything else is rounding error by comparison. If you want the full breakdown of where the weight accumulates, Why Your PDF Is So Large (and What to Strip) walks through each cause with the relative magnitudes.

The Two Kinds of PDF Compression

Every technique falls into one of two buckets, and confusing them is the source of most disappointment.

Lossless: structural optimisation

These operations rewrite the file more efficiently without changing a single rendered pixel:

• Object streams. PDF 1.5 introduced the ability to pack many small objects into one compressed stream instead of storing each separately with its own overhead. Files written by older generators — or by software targeting maximum compatibility — skip this and pay for it.
• Cross-reference streams. The lookup table that maps object numbers to byte offsets can itself be compressed rather than written as plain text.
• Resource deduplication. The same logo placed on 200 pages is often embedded 200 times by naive generators. It only needs to exist once, referenced 200 times.
• Removing orphans. Deleted pages, superseded incremental-update revisions, unused fonts, and stale annotations linger in files that were edited repeatedly. Rewriting the document drops anything nothing points to.
• Recompressing Flate streams at a higher effort level. Same algorithm, more CPU time spent searching for matches, a few percent smaller.

All of this is safe. None of it is dramatic. On a modern, cleanly generated PDF, lossless optimisation typically recovers somewhere between nothing and 15%. On a file that has been edited a dozen times in a form-filling application, it can occasionally recover far more — but that is recovering waste, not compressing content.

Lossy: image recompression and downsampling

This is where the big numbers come from, and it is a genuine quality trade:

• Downsampling reduces an image's pixel dimensions — a 600 DPI scan resampled to 200 DPI holds one ninth the pixels.
• Re-encoding converts an image to a lossier codec or a lower quality setting: a Flate-compressed screenshot becomes a JPEG, or a quality-95 JPEG becomes quality-70.
• Colour reduction turns a 24-bit colour scan of a black-and-white document into greyscale or bilevel, cutting the data by three to twenty-four times.

Anyone promising an 80% reduction with "no quality loss" is doing one of these and hoping you do not zoom in. The honest framing is that the loss is often imperceptible at your actual viewing size — which is a perfectly good outcome, just not the same claim. How to Compress a PDF Without Losing Quality takes that specific promise apart and explains how far you can actually push it.

Where the Bytes Actually Go

It helps to have rough magnitudes in mind before you start optimising anything.

Content	Typical size
One page of formatted text, fonts subset	20-80 KB
One page of text with a full embedded font family	300 KB-2 MB (first page only)
A 150 DPI colour scan of one A4 page, JPEG	150-400 KB
A 300 DPI colour scan of one A4 page, JPEG	500 KB-1.5 MB
A 300 DPI colour scan stored uncompressed or Flate	8-25 MB
A 600 DPI colour scan of one A4 page	4-30 MB depending on encoding
A phone photo of a document pasted at full resolution	2-8 MB

Read that table and the arithmetic of a bloated file becomes obvious. A 40-page scanned contract at 300 DPI in colour is comfortably 40 MB. The same contract scanned bilevel at 300 DPI with CCITT Group 4 encoding — the correct setting for black text on white paper — is closer to 2 MB, with no meaningful loss of legibility, because the source material genuinely has two colours in it.

When you are checking whether you have hit a portal's limit, remember that the limit and your file manager may not agree on units. A "10 MB" cap is sometimes 10,000,000 bytes and sometimes 10,485,760. The Digital Data Storage Converter settles that quickly if you are hovering near the boundary.

The Practical Approach: Compress Before the PDF Exists

Here is the workaround that genuinely works, and it follows directly from everything above: a PDF's size is mostly decided before the PDF is created. Once a 6 MB photo has been embedded into a page, getting it out again means re-encoding it and accepting the loss. Getting it right beforehand costs nothing.

If you are building a PDF from images — scans, phone photos of receipts, screenshots for a report — the workflow that avoids the problem entirely is:

1. Collect your images first, before converting anything to PDF.
2. Compress them as images, where you have real control and can see exactly what you are trading. Our Image Compressor handles up to 20 files at once with a quality slider or a target file size, and shows a genuine before/after preview for each one so you can judge the result at the size you will actually view it. Everything runs in your browser — no upload.
3. Check the format decision if you are unsure whether JPEG, WebP, or PNG is the right container for a given page. The Image Compression & Format Size Estimator predicts the savings for each before you commit to a batch.
4. Convert to PDF, using your scanner software, your phone's document mode, or your operating system's print-to-PDF.
5. Combine the results in the PDF Merger if you ended up with several files. It copies pages without re-encoding them, so the sizes you carefully established survive intact.

A 30-page scanned document assembled this way routinely lands under 3 MB. The same document assembled carelessly — full-resolution phone photos, straight to PDF — lands at 90 MB, and no compression pass afterwards recovers the quality you would then have to destroy to fix it.

When You Are Stuck With an Existing Large File

Sometimes the PDF already exists and you did not create it. The decision tree is short:

Is the text selectable? Try to highlight a sentence. If it highlights, the pages are real text and the file is large for another reason — probably embedded fonts or a handful of oversized images. If nothing highlights, every page is an image, and the file's size is entirely an image problem.

Do you control the source? If the PDF came from a document you still have — a word processor file, a design file, a spreadsheet — regenerating it with better export settings beats compressing the output every single time. Most export dialogs have a "minimum size / web" preset that downsamples images and subsets fonts in one step.

Can you split instead of compress? If a portal wants under 5 MB and you have a 20 MB document, sending the relevant 6 pages may be both smaller and more appropriate than degrading all 80.

Do you need a desktop tool? For an existing file with no available source, genuine recompression requires software that can decode and re-encode image XObjects in place. Ghostscript's -dPDFSETTINGS=/ebook preset is the standard free answer on desktop, and desktop is the right place for it: the file stays on your machine, and you can compare against the original before overwriting anything. We would rather point you there than pretend a browser tool we have not built can do it.

Keeping Quality Where It Matters

Two habits prevent almost every compression regret.

Always keep the original. Lossy compression is one-directional. Archive the full-resolution version somewhere and treat the compressed file as a derivative made for a specific purpose — email, upload, web publishing. When a different purpose comes along, go back to the original rather than compressing the compressed copy, which stacks artefacts on artefacts.

Match the setting to the destination, not to a habit. 600 DPI is right for archival scanning of a signed original. It is absurd for a receipt going into an expense claim that a human will glance at on a phone. Scanning everything at maximum settings "to be safe" is the most common cause of files that later need rescuing.

Conclusion

PDF compression is less mysterious than it looks once you stop treating a PDF as a single blob. It is a container of independently compressed streams, and in practice one category — embedded raster images — accounts for the overwhelming majority of the weight in any file that feels too large. Lossless structural optimisation is real and safe but modest. The dramatic reductions people expect come from recompressing and downsampling images, which is a quality trade whether or not the tool doing it says so.

That means the highest-leverage moment is before the PDF exists. Compress and size your images while they are still images, using the Image Compressor, then convert and combine them in the PDF Merger — all of it in your browser, none of it uploaded. Get the inputs right and the output rarely needs rescuing.