PDF Compression Explained: How File Size Actually Shrinks

Why PDF File Size Is Not What You Think

Most people assume a PDF is just a snapshot of a document — a static container that holds what you see. That mental model is wrong, and it's why so many people are confused when a 40-page report balloons to 80 megabytes while a 200-page novel weighs in at under 2 MB. PDFs are structured archives. They contain discrete, separable streams of data — images, fonts, content instructions, metadata, thumbnails, form fields — each of which can be compressed (or not) independently. When you "compress a PDF," you're not squeezing one thing. You're trimming, encoding, and discarding multiple distinct data types simultaneously.

Understanding this matters because it tells you exactly where to look when a file is too large, and it prevents you from wasting time running a compression tool that optimizes the wrong thing. Let's go through each major lever in order of impact.

Image Downsampling: The Biggest Weight Loss

If your PDF contains photographs or scanned pages, images are almost certainly responsible for the majority of the file size. A single full-resolution scan at 600 DPI can easily consume 15–25 MB before compression. Most PDFs intended for screen viewing or email need nothing close to that resolution.

Downsampling reduces the pixel dimensions of embedded images so they match a target output resolution rather than the resolution at which they were originally captured. The three common downsampling methods are:

• Average downsampling: Averages the pixels in a sample area and replaces the entire region with that average color. Fast, but can produce slight blurriness.
• Subsampling: Picks the center pixel from each sample area and discards the rest. The fastest method, but quality suffers most noticeably on diagonal edges.
• Bicubic downsampling: Uses a weighted average of surrounding pixels, applying more weight to pixels closer to the center. Slower, but produces the cleanest result — it's the default in most professional tools including Adobe Acrobat's optimizer.

Practically speaking: images destined for a screen don't need more than 150 DPI. Images meant for standard office printing need around 300 DPI. Anything above that in a PDF intended for distribution is dead weight. A 600 DPI color photograph downsampled to 150 DPI loses 93.75% of its pixel count. That directly translates into file size reduction before any encoding even happens.

After downsampling, the image data is re-encoded. This is where the choice of image format matters. PDFs can embed images using JPEG, JPEG 2000, JBIG2 (for monochrome), CCITT Fax, or ZIP (lossless). For color photographs, JPEG at a quality level of 55–75 typically delivers files roughly 80–90% smaller than lossless equivalents with no perceptible degradation on screen. JBIG2 is particularly effective for scanned text pages with only black and white content — it applies a pattern-matching approach where similar character shapes are referenced from a shared dictionary rather than individually encoded, achieving compression ratios that JPEG cannot touch on binary content.

Font Subsetting: Carrying Only What You Need

Fonts are another major contributor to PDF bloat, and they're often overlooked. When a font is embedded in a PDF, the file includes the actual glyph outlines so the document renders identically on any machine, regardless of whether the recipient has that font installed.

The problem: a professional typeface can contain 3,000 to 10,000 glyphs. Extended Unicode fonts supporting multiple scripts are larger still. If your document only uses 200 of those glyphs, embedding the full font means paying for roughly 2,800 to 9,800 glyphs you never needed.

Font subsetting solves this by stripping the embedded font down to only the glyphs actually present in the document. A body text font that might otherwise consume 400 KB gets trimmed to 30–60 KB. Multiply that across five or six fonts in a document and you've shed several megabytes before touching a single image.

There is one legitimate trade-off: a subsetted font cannot be used for editing without re-embedding the full version. If you're distributing a final document that no one is supposed to edit, subsetting is the right choice. If the file needs to remain editable by recipients, full embedding is safer. Most PDF/X and PDF/A standards actually mandate subsetting for exactly this reason — the goal is archival fidelity, not editability.

A related technique is font deduplication, which runs before subsetting. Complex documents assembled from multiple source files sometimes embed the same font multiple times — once from each original file. The optimizer identifies duplicates and consolidates them into a single reference. On documents produced by merging several reports, this alone can cut font-related overhead in half.

Stream Compression: The Background Efficiency Layer

Beyond images and fonts, a PDF contains content streams — the instructions that describe text placement, vector graphics, color fills, line paths, and page geometry. These streams are plain text-like sequences of PDF operators, and they compress extremely well.

The standard compression algorithm applied to content streams is Flate compression, which is the same algorithm underlying gzip and PNG files. It works by identifying repeated byte sequences and replacing them with compact references. Content streams are highly repetitive — the same operators appear over and over across pages — so Flate compression typically achieves 60–80% reduction on stream data alone.

What's less obvious is that some PDFs, particularly those created by older or poorly configured tools, contain uncompressed or partially compressed streams. Running an optimizer over such a file and enabling Flate on all streams can dramatically shrink the file without touching a single image or font.

A closely related operation is object stream compression, introduced in PDF 1.5. Instead of storing each PDF object (pages, annotations, metadata entries) as a separate uncompressed block, object streams pack multiple small objects together and compress the whole group. This is particularly effective on documents with many small objects, such as forms with dozens of fields or documents with extensive annotation layers. Tools that target PDF 1.5 or later can leverage this; tools targeting PDF 1.4 compatibility cannot.

What Else Gets Stripped During Optimization

A properly implemented PDF compressor doesn't just encode data more efficiently — it also removes data that should never have been in the distributed file in the first place.

• Metadata bloat: Some authoring applications embed extended XML metadata (XMP) with creation history, revision logs, or application-specific fields. Unless you need this for archival purposes, it's disposable.
• Embedded thumbnails: Older PDF workflows embedded a small preview thumbnail for every page so that file managers could display them without fully parsing the file. Modern operating systems generate their own thumbnails on the fly. These embedded thumbnails add size with no benefit.
• Duplicate resources: Beyond fonts, images are sometimes duplicated — the same image embedded separately on each page rather than defined once and referenced multiple times. A decent optimizer detects this through content hashing and consolidates the duplicates.
• Deleted content artifacts: When you edit a PDF by deleting pages or objects, the original content isn't actually removed — it's just marked as unused. The space isn't reclaimed until the file is linearized or re-saved with a full rewrite. An optimizer that does a complete object rebuild removes all this dead data.
• Linearization data: PDFs can be "linearized" (also called "fast web view") so that the first page loads before the entire file downloads. If you don't need this for web delivery, the linearization structures add overhead with no payoff for email or download scenarios.

How Lossy Versus Lossless Compression Affects Quality

Every compression technique falls into one of two categories: lossless (the original data can be reconstructed exactly) or lossy (some information is permanently discarded to achieve smaller size). Font data, vector graphics, and content streams should always be compressed losslessly — you can't afford to corrupt coordinate data or text instructions. Images are where the lossy/lossless decision becomes consequential.

For photographs and complex color images, JPEG compression is lossy and the right default for most use cases. The quality slider in compression tools isn't arbitrary — it controls the quantization table applied during the discrete cosine transform that JPEG uses. Setting quality too low introduces blocking artifacts visible as pixelated squares, particularly around edges. A quality level of 60–75 (on a 0–100 scale) is the practical sweet spot for documents intended for screen or standard printing.

For diagrams, charts, screenshots of text, or any image with sharp edges and flat color regions, JPEG is the wrong choice. These images compress better and without artifacts under lossless methods like PNG-within-PDF (using Flate encoding). Many professional PDF optimizers detect image content type automatically and apply the appropriate codec per image rather than a uniform setting across the whole document.

The Practical Hierarchy When Optimizing a Large PDF

1. Downsample and re-encode images first — this is where 70–90% of the savings come from in typical documents.
2. Enable font subsetting and deduplicate any repeated fonts.
3. Apply Flate compression to all uncompressed or partially compressed content streams.
4. Strip embedded thumbnails, unused objects, and deleted content.
5. Consider object stream compression if the target audience uses modern PDF readers (PDF 1.5+).

Running these steps in order lets you measure the impact of each stage, which is useful when you need to preserve quality in specific areas — for instance, keeping product photography at 300 DPI while aggressively downsampling background textures to 96 DPI.

PDF compression is not a black box. Each kilobyte removed corresponds to a specific decision about a specific kind of data. When you understand the machinery, you can make those decisions deliberately — and get a file that's genuinely smaller without giving up anything you actually needed.