Why Some PDFs Compress 90% and Others Barely Budge

Drop two PDFs into the same compressor and one goes from 40 MB to 3 MB while the other goes from 2 MB to 1.9 MB. It looks like the tool is inconsistent, but almost always the difference is in the files. A PDF isn’t one compression format. It’s a container holding several kinds of data, each compressed its own way, and a compressor can only help with the parts that still have slack in them.

Where the bytes go

A PDF is a collection of numbered objects: pages, fonts, images, bookmarks. Anything large is stored as a stream, and three kinds of stream account for nearly all the weight.

Component	What it holds	Typical size
Images	Photos, scanned pages, screenshots	Hundreds of KB to several MB per photo
Fonts	Glyph outlines for the typefaces used	Tens of KB for a Latin subset; several MB for a full Chinese, Japanese or Korean font
Content streams	Instructions that place text and draw lines and shapes	A few KB per page normally; megabytes for detailed drawings and maps

A 30-page report written in Word is mostly text, so its content streams are small and fonts dominate. A scanned contract is one image per page, and images make up 95% or more. An architectural drawing exported from CAD may contain no images at all yet carry tens of megabytes of content streams, because every one of its hundreds of thousands of line segments is an instruction. Whether a compressor can help is decided by this split before it does anything.

The filters on each stream

The PDF standard, ISO 32000, has every stream declare how it’s encoded in a /Filter entry, and the viewer picks a decoder by that name. The ones you’ll meet:

• FlateDecode is zlib/deflate (RFC 1950/1951), the same lossless algorithm PNG uses. Most content streams, fonts and lossless images use it. For images it can be paired with a PNG-style predictor, which stores each row as differences from neighboring pixels and makes the data far more compressible.
• DCTDecode is baseline JPEG. The bytes in the PDF are literally a JPEG file.
• JPXDecode is JPEG 2000, added in PDF 1.5. It can beat JPEG at the same quality, but fewer tools can process it.
• CCITTFaxDecode is fax compression for 1-bit images (ITU-T T.4 and T.6, Group 3 and Group 4). It has been the workhorse for black-and-white scans for decades.
• JBIG2Decode, added in PDF 1.4, is also for 1-bit images. It can store each distinct glyph shape once in a symbol dictionary and then record only positions, which makes scanned text pages tiny.
• LZWDecode, RunLengthDecode, ASCIIHexDecode, ASCII85Decode are older schemes or text-safe encodings. The ASCII ones actually make data larger.

One consequence matters more than any of the details: data that’s already JPEG or JBIG2 doesn’t get meaningfully smaller if you wrap it in Flate. Compressed data is statistically close to random, so a lossless compressor has no repetition to find. It’s the same reason zipping a PDF rarely changes its size.

When a PDF shrinks a lot

Big wins almost always come from one of three situations.

Images stored at far more resolution than they’re displayed at. Phone cameras produce 12-megapixel images (4000×3000) as a matter of course. Fill an A4 or Letter page with one and it sits at roughly 340 DPI. For screen reading or an office printer, 150 DPI is plenty. Downsampling to 150 DPI scales each dimension by about 0.44 and keeps about 19% of the pixels, and since JPEG size roughly follows pixel count, the image ends up near a fifth of its former size. If the photo was placed at half-page size, the placed DPI doubles and the savings get even bigger.

Uncompressed images. Older software and some scanner drivers store images raw, or with Flate but no predictor. A full A4 page in 24-bit color at 300 DPI is 2481 × 3508 × 3 bytes, about 26 MB. Converting that to JPEG alone cuts it by an order of magnitude or more.

Editing baggage. A PDF saved from Illustrator with editing capabilities preserved carries the full native artwork inside it. Files assembled from many PDFs can contain the same fonts and logo once per source document. Both can be removed without touching image quality.

When a PDF barely shrinks

Files that resist every compressor usually have an equally clear reason.

Photos already JPEG’d at a sensible resolution. A photo stored around 150 DPI at quality 75 only loses a few percent when re-encoded, and every JPEG round trip adds block edges and color smearing. A well-behaved compressor leaves such images alone when the saving is small.

East Asian fonts embedded in full. A Latin font needs a few hundred glyphs. A Korean font covering all 11,172 precomposed Hangul syllables plus Chinese characters is several megabytes, and Japanese and Chinese fonts are similar. Embedding only the characters the document uses (a subset) drops that to a few hundred kilobytes or less. Subsetting means rebuilding the font, so it’s best done in the app that creates the PDF; Word, InDesign and most office suites have the setting in their PDF export options.

Vector drawings. Each line is a move-to and a line-to instruction, so complexity turns directly into content stream bytes. If those streams are already Flate-compressed, cranking the level up gains a few percent at most. The real fix is exporting from CAD without unneeded layers.

Black-and-white scans. If the scanner already saved pages as JBIG2 or CCITT Group 4, they’re small to begin with and there’s little left to take.

Object streams: compressing the structure itself

Up to PDF 1.4, dictionary objects such as page descriptions and font descriptors were stored as uncompressed text, and the cross-reference table at the end had a fixed 20-byte line per object. In a document with tens of thousands of objects, that adds up.

PDF 1.5 introduced two fixes. Object streams pack many objects into one Flate-compressed stream, and cross-reference streams store the xref table itself as compressed binary. Streams (images, font data and so on) can’t go inside object streams, so the gain is limited to structural data. It’s noticeable on heavily tagged accessible PDFs and very long documents, and close to nothing on a photo-heavy file.

Scans and MRC

Color scans are the hard case. Text needs crisp edges; backgrounds and photos need smooth tones. No single codec does both well. Low-quality JPEG rings around every letter, and lossless keeps the file enormous.

Mixed Raster Content (MRC, ITU-T T.44) solves this by splitting a page into layers. The letter shapes go into a high-resolution 1-bit mask (JBIG2 or Group 4), and the text color and background go into low-resolution color images (typically JPEG). The mask decides which layer shows through at each pixel. In PDF this is built from ordinary features like image masks and soft masks, so any viewer can open it. The ‘high compression’ mode in commercial scanning software is usually MRC, and it can hold a color scan in tens to hundreds of kilobytes per page.

There’s a caveat. JBIG2’s lossy mode merges glyphs that look alike into one symbol. In 2013, David Kriesel showed that Xerox multifunction devices were silently swapping digits, such as a 6 for an 8, in scanned documents, and the cause was exactly this symbol merging. For accounting, medical or legal documents where numbers matter, lossless JBIG2 or Group 4 is the safer choice.

Recipes

A photo-heavy expense report over the email limit. This is the classic high-image-share, high-placed-DPI case. Running Compress PDF at 150 DPI fixes most of them. If the photos aren’t in a PDF yet, shrinking them first with the image compressor gives a lighter, more predictable result.

A report weighed down by fonts. Skip the compressor and look at the export settings in the app that made it. Keep font embedding on, but embed only the characters used.

A color document that will be printed in black and white. Converting it with Grayscale PDF makes contrast on a mono printer predictable. Be aware that grayscale conversion re-stores color JPEGs as lossless gray images, so photo-heavy files may grow. If size matters, convert first and compress second. Doing it the other way round means the grayscale step unpacks your freshly compressed JPEGs back into lossless data.

A scanned contract. Solve it at scan time if you can. For text-only pages, 300 DPI black-and-white (1-bit) saved as Group 4 or lossless JBIG2 is the smallest and sharpest option. If stamps or colored signatures matter, use the scanner’s MRC mode. When compressing an existing color scan, going below 150 DPI can make small print hard to read.

A signed PDF. Every compressor rewrites the file, which invalidates digital signatures. Compress before signing, never after.

Common misconceptions

“Zipping a PDF makes it smaller.” The streams inside are already compressed, so the archive barely changes. The exception is a rare uncompressed, text-only PDF.

“Running compression repeatedly keeps shrinking it.” Once images are at the target resolution there’s nothing left to downsample. Lowering quality further does shrink the file, but losses stack up with each pass.

“Higher DPI is always better.” Pixels beyond what the placed size needs get thrown away by the printer. For office output, 150–200 DPI is enough, and 300 DPI covers most high-quality print.