What is PDF Compression and How Does It Actually Work?

When someone tells you to "compress a PDF" before emailing it, you probably just use a tool and hope for the best. Understanding what's actually happening during compression helps you make better decisions — choosing the right quality level, knowing which files will compress well and which won't, and understanding why some PDFs refuse to get much smaller regardless of what you do.

What makes a PDF file large in the first place?

A PDF is a container. It holds different types of content: text, images, fonts, vector graphics, and structural metadata. Each of these contributes to file size in different ways.

Images are typically the biggest contributor to PDF file size. A single full-resolution photograph can be 3-8MB on its own. When embedded in a PDF without compression, it stays that size. Most of a 20MB PDF's bulk is usually the images inside it.

Fonts add 100-400KB per typeface. PDFs often embed entire font files to ensure correct rendering on systems that don't have the font installed. A document using five different fonts might embed 1-2MB of font data.

Text content itself is compact — a page of typed text is only a few kilobytes when compressed. Text is rarely the problem.

Metadata and structure includes revision history (from repeated editing and saving), embedded thumbnails, form data, XMP metadata, and the structural cross-reference table. In heavily edited documents, this overhead can add 500KB to several MB of essentially invisible data.

Lossless vs lossy compression

This distinction matters a lot for understanding what's happening to your document.

Lossless compression reduces file size without discarding any data. The original content can be perfectly reconstructed from the compressed file. Examples include ZIP compression, PDF object stream compression, and metadata stripping. When you remove metadata and revision history from a PDF, you're doing lossless compression — the visible content is completely unchanged.

Lossy compression discards data permanently to achieve greater size reduction. JPEG compression of images is the classic example. When a JPEG image is re-encoded at lower quality, some image detail is permanently discarded and the image is slightly less sharp. The trade-off is that lossy compression can reduce file sizes far more dramatically than lossless approaches.

Most PDF compressors do both: lossless cleanup of structure and metadata, followed by lossy re-encoding of embedded images at lower quality to achieve significant size reduction.

What happens when you compress a PDF with PDF99?

When you use the PDF99 Compress PDF tool, the compression process works in stages.

First, metadata is stripped. Title, author, subject, keywords, revision history, and embedded thumbnail images are all removed. This alone can reduce certain PDFs by 10-30%, particularly files that have been through multiple rounds of editing in Word or Acrobat.

Second, if PDF.js is available and you've chosen a quality setting below 90%, each page is re-rendered at your target DPI and re-encoded as a JPEG image at your chosen quality level. This is where most of the size reduction comes from for image-heavy documents. The trade-off is that re-rendering effectively converts the page to a raster image — if the original had vector graphics or was created digitally, the output will be slightly less crisp at high zoom levels.

The quality slider controls how aggressively images are re-encoded. At 90%, the visual difference from the original is imperceptible to most people. At 50%, images are noticeably softer but text remains readable. At 30%, the document is functional but image quality is visibly degraded.

Why do some PDFs barely compress?

If you run a PDF through a compressor and it barely shrinks, there are a few likely reasons.

The PDF was already optimised when created. Modern PDF creation software (Adobe InDesign, the latest Acrobat, most cloud document services) already applies compression during export. There's little left to squeeze out.

The PDF contains mostly text and vector graphics. These compress very efficiently already. A text-only legal document might be 200KB with minimal image content — compressing it to 180KB is about the best you can do.

The images inside the PDF are already JPEG-compressed at a similar quality level to what you're targeting. Re-encoding an already-compressed JPEG doesn't make it significantly smaller — it just loses a bit more quality with minimal size benefit.

The right quality setting for different use cases

75-85% quality: ideal for most business documents that will be read on screen or printed at A4/Letter size. The compression is significant (typically 40-70% reduction) and the visual difference from the original is imperceptible in normal use.

50-65% quality: suitable for documents where file size is the priority and fine image detail isn't critical. Web previews, quick-share documents, and filing copies work well at this level.

Below 50%: use only when you have a hard file size limit and no other option. Text remains readable but photographic content will look clearly compressed.

Compression in practice: a before and after

To make compression tangible, consider a typical scenario. A 10-page report created in Microsoft Word, with several charts and two embedded photographs, exports to PDF at around 4.5MB. Running it through PDF99's compression tool at 75% quality and 150 DPI reduces it to approximately 1.1MB — a 76% reduction. Open both files side by side at 100% zoom and they look identical. Zoom to 400% on a photograph and the compressed version shows slightly softer edges. At any size a human would normally read a document, the difference is invisible.

Now take a different document — a 20-page scanned contract, photographed with an office scanner at 300 DPI and saved without any compression. The PDF starts at 18MB. At 75% quality and 100 DPI, it compresses to 1.8MB. At 50% quality and 72 DPI, it drops to 680KB. The text remains readable at both settings when viewing at normal reading size, though fine print in footnotes becomes noticeably softer at the more aggressive setting.

These examples illustrate why there's no single "right" compression setting. It depends on what the PDF contains, how it will be used, and how small it needs to be.

What metadata stripping does — and what it doesn't do

Before re-encoding images, PDF99 strips document metadata: the title, author, subject, keywords, creator application, producer, and creation date stored in the PDF's document info dictionary. It also removes revision history — the record of previous edits that PDF editors like Acrobat append to the file each time you save. In heavily-edited documents this revision history can add 500KB to several megabytes of invisible overhead.

Metadata stripping alone sometimes produces surprising results. A 3MB PDF that contains only text and simple graphics might drop to 1.8MB just from removing metadata and revision history — no image recompression at all. If your PDF was created from a Word document that went through 20 rounds of tracked changes, the revision history can dwarf the actual content in terms of file size.

What metadata stripping doesn't do: it doesn't touch the visible content of the document in any way. No text is changed, no images are resampled. It's a purely structural operation that removes data the reader never needed to display the document.

Choosing between quality levels: a practical guide

The quality setting in PDF99's compressor controls how aggressively JPEG re-encoding is applied to embedded images. Here's a practical guide to choosing the right level for common use cases.

90% quality: Indistinguishable from the original at any normal viewing size. Use this when quality is paramount and you just want to strip metadata and remove revision history. File size reduction is modest — 10-30% for most documents.

75-80% quality: The sweet spot for most purposes. Virtually no visible difference at reading size. Photographs look sharp, text is crisp, diagrams render cleanly. File size reduction is typically 40-65%. This is the default for good reason.

60-70% quality: Appropriate when you need to hit a specific size target (like a 500KB portal limit) and the document is image-heavy. Slight softening visible on photographs when zoomed. Text remains perfectly sharp throughout.

Below 50% quality: Use only when a hard size limit leaves no other option. Text remains readable. Photographic content shows visible JPEG blocking artefacts. Appropriate for scanned documents where content legibility is the only requirement, not appearance.

Browser-based vs server-side compression: what's the difference?

PDF99 compresses PDFs entirely in your browser using PDF.js and PDF-lib. This approach has specific implications worth understanding.

Browser-based compression is private — your PDF never leaves your device. It also means compression speed depends on your device's processing power rather than a server's capacity. A complex 50-page PDF might take 30-60 seconds on an older phone but under 10 seconds on a modern laptop.

Server-side PDF compression tools (where you upload to a server and download the result) can sometimes achieve better compression ratios because they have access to more sophisticated tools — Ghostscript, for example, can perform optimisations that JavaScript PDF libraries can't replicate in a browser context. The trade-off is that your document travels to and from a remote server, which raises privacy considerations for sensitive documents.

For everyday documents — CVs, invoices, reports — browser-based compression at PDF99 achieves more than adequate reduction. For highly sensitive documents, the in-browser approach means your file never leaves your device. For situations where you need maximum compression and privacy is less of a concern, a server-side tool with Ghostscript may produce a smaller result.