PDF Compression Not Working: Why Files Stay Large and How to Fix It

PDFs are not monolithic files. They are containers that hold text, fonts, images, vector graphics, metadata, and structural data — each stored differently. Compression works primarily on images and uncompressed streams. If those are already compressed, there is little a tool can do. A PDF exported from a modern word processor (Word, Google Docs) typically has small embedded images compressed with JPEG or Deflate, and text stored as compact vector outlines. These files are already near their theoretical minimum size. Running them through a compressor might save 1–5% — sometimes nothing at all. Scanned PDFs are the opposite: each page is typically stored as a high-resolution JPEG or TIFF, often at 300 DPI with minimal compression applied during scanning. These are the files where compression shines, because the images can be recompressed at lower quality settings or downsampled to screen resolution.

1. 1Open the PDF and check what type of content it contains — is it text-based, image-heavy, or scanned?
2. 2Check the current file size and page count to calculate size per page; scanned PDFs over 500 KB/page benefit most from compression.
3. 3Try compressing with a 'screen quality' or 'aggressive' setting rather than the default — higher compression trades some image quality for significant size reduction.
4. 4If the tool offers DPI settings, reduce the output DPI from 300 to 150 for documents that will only be viewed on screen.

One of the most overlooked causes of large PDFs is embedded font data. A PDF that uses many different fonts — especially designer fonts or icon fonts — embeds the full font file for each one. A single font subset can add 50–200 KB to a file. Documents using ten or more fonts from a design application like Adobe InDesign can reach several megabytes before any images are added. Most compression tools do not remove embedded fonts, because doing so would make the text render incorrectly on systems that do not have those fonts installed. Ghostscript, the engine behind LazyPDF's compression, does subset fonts — it removes the characters from the font file that are not used in the document — which reduces font overhead significantly. If fonts are a major contributor to your file size, re-exporting the PDF with the 'subset fonts' or 'optimize for web' option enabled in the source application is more effective than post-export compression.

1. 1Re-export the PDF from its original application with 'Subset embedded fonts' enabled.
2. 2In Word, use File → Save As → PDF → Options and check 'Bitmap text when fonts may not be embedded' to reduce font data.
3. 3Use LazyPDF's Compress with Ghostscript, which automatically subsets fonts during compression.
4. 4For design-heavy PDFs, flatten transparency and convert spot colors to CMYK before export to reduce complexity.

JPEG compression is lossy — once an image has been compressed to JPEG, recompressing it at the same quality level saves almost nothing, and recompressing at lower quality degrades it visibly while offering only marginal additional size reduction. This is the diminishing returns problem, and it affects any PDF that was exported with already-compressed images. A PDF created from a PowerPoint with JPEG slides, for example, may refuse to shrink meaningfully because every image is already a JPEG. The compressor scans the file, finds JPEG streams, and correctly determines that further JPEG compression would destroy quality without meaningful space savings. The only effective approach in this scenario is to reduce image resolution. Downsampling from 300 DPI to 96 DPI for screen-only documents cuts image data by roughly 90%, regardless of the existing compression format. LazyPDF's compressor uses Ghostscript's `-dPDFSETTINGS=/screen` preset which automatically downsamples images to screen resolution when selected.

Most compression tools offer multiple quality tiers. The labels vary — 'screen', 'ebook', 'printer', 'prepress' in Ghostscript terminology, or 'low/medium/high' quality in consumer tools — but they all represent a tradeoff between output file size and image quality. For documents you will only email or read on a monitor, screen-quality compression (72–96 DPI) is entirely appropriate. The text remains sharp because PDF text is vector-based and not affected by DPI settings, but images will lose fine detail. For documents that will be printed, use a medium or printer-quality setting to preserve image fidelity. Many users try the default or 'balanced' setting and see minimal reduction, then give up. The key insight is that significant size reduction requires an aggressive setting. If your PDF is not shrinking, try the next compression level down and assess whether the quality loss is acceptable for your use case.

Some PDFs are created by tools that apply aggressive optimization at export time: Google Chrome's 'Save as PDF', macOS's Quartz PDF filter, and modern versions of Microsoft Word all produce well-optimized PDFs by default. These files compress poorly because the source tool already did the compression work. In this case, the only remaining options are structural: linearizing the file (optimizing for web viewing), removing metadata, removing JavaScript, or removing embedded thumbnails. These structural optimizations typically save 5–15% on an already-efficient PDF. If you need the file smaller than what compression achieves, the most effective option is to reduce the source content: lower image resolution before importing into the document, reduce the number of pages, or split the document and send only the relevant pages. LazyPDF's Split tool lets you extract only the pages a recipient actually needs, which is often more effective than compression alone.