Why Your PDF Won't Compress — And How to Fix It

By PDFwarp · · 6 min read

Why some PDFs barely shrink (or grow) when you compress them, what is actually inside the file that fights compression, and the right way to get a smaller PDF without destroying quality.

You upload a 5 MB PDF to a compressor, wait thirty seconds, and download a file that is — somehow — still 5 MB. Or you set the compression level to "Low" expecting a modest reduction, and the tool tells you no reduction was possible. This experience is more common than most people realize, and it is almost never the compressor being broken. It is the PDF itself fighting back.

Here is exactly what is happening inside a stubborn PDF, and the right way to get it smaller without destroying quality.

Most PDFs Are Already Compressed

PDF is not one format. It is a container that wraps a mix of compressed and uncompressed content — fonts, vector drawings, raster images, embedded files, form fields, and metadata. When you "compress a PDF" you are not flattening one block of data; you are asking a tool to find places where the existing compression is sloppy and tighten them up.

The catch is that modern PDF generators already do this. When you export from Word, Pages, Google Docs, or any modern design tool, the images inside the PDF are already JPEG-compressed at reasonable quality, the text streams are already deflate-compressed, and the fonts are already subsetted. Running another compressor over the file finds very little to remove.

For PDFs created in the last decade by mainstream tools, a 0–5% reduction at low compression is normal. The PDFs that shrink dramatically — 50%, 80%, 95% — are almost always older files, scanned documents at high DPI, or PDFs assembled from oversized source images.

The Three Reasons Your PDF Won't Shrink

1. The embedded images are already compressed at typical web quality. Compressors shrink image-heavy PDFs by re-encoding the embedded images at lower quality or lower resolution. If the source images were already saved at JPEG quality ~75 and resolution ~150 DPI — the default for almost every PDF export from the last ten years — re-encoding them at similar quality produces a file the same size or larger. Asking for "low compression" (preserve maximum quality) on this kind of PDF will frequently produce no reduction at all. PDFwarp handles that case by handing back your original file rather than serving you a slightly bigger version with the word "compressed" in the filename.

2. The bulk of the file is text and vector graphics, not images. A fifty-page contract is almost entirely text plus a logo or two. The text is already stored compactly — there is no equivalent of "re-encode at lower quality" for words. You can subset fonts, deduplicate identical resources, and tighten metadata, but you cannot shrink the actual content of a sentence. For text-heavy PDFs, a 3–10% reduction is the realistic ceiling, and that is what a good compressor delivers.

3. The PDF was already compressed by a previous tool. If you have compressed the file before — by you, by your email client, or by someone else in the chain — most of the easy savings are already gone. Compression does not stack. After the first pass, the file is at or near its quality-floor for the chosen level.

How to Tell What Is Inside Your PDF

You can usually predict how well a PDF will compress just by looking at it.

If you are not sure, upload the file to Compress PDF and look at the preview. PDFwarp runs all three levels and shows the resulting size for each before you commit. If High and Medium both produce roughly the original size, your file is text-bound — no compressor will help much.

Match the Level to the File

The three compression levels target different content types, and picking the wrong one for your PDF is the most common reason people are disappointed.

High uses Ghostscript's screen preset — 72 DPI downsampling and aggressive JPEG re-encoding. For image-heavy PDFs this routinely produces 70–95% reductions. Right choice for documents you intend to view on screen, share by email, or upload as web previews. Avoid for anything you will print at full size.

Medium downsamples images to 150 DPI and re-encodes at moderate JPEG quality. A solid middle ground — readable print quality, roughly half the file size on image-heavy documents, text untouched. This is the default and the right pick when you do not know what is inside your PDF.

Low is for documents where preserving image quality matters more than maximizing reduction. It only downsamples images noticeably above 400 DPI and re-encodes at near-original quality. This is the setting for legal documents, archival material, anything that might be printed at full size, and any PDF where someone might zoom in on a detail. Smaller reductions, but it will not visibly damage the file.

If you pick Low and the tool tells you no reduction was possible, that is the honest answer — not a bug. Your PDF is already at or near the quality you asked us to preserve.

When Compression Hurts More Than It Helps

A few categories of document should usually skip compression entirely.

Scanned legal contracts. The signatures and notary seals are the point of the document. Aggressive compression introduces JPEG artifacts that visibly degrade them — fine for screen viewing, not fine if the document might be challenged or printed for filing.

Archival scans. If you are scanning to preserve a document for the long term, leave it at the highest quality. Storage is cheap; rescanning is not.

OCR'd documents. PDFs that have had a text layer added by OCR (like AI Scan to Text) should generally not be re-compressed afterwards. OCR adds precise text positioning that aggressive compression can occasionally disrupt.

PDFs with form fields you still need to fill. Some compression modes flatten interactive form features. Fill the form first, then compress.

What to Try When Standard Compression Won't Deliver

If you have a PDF that genuinely needs to be smaller and standard compression is not getting you there, a few options bypass the normal limits.

Rescan at lower DPI. If the PDF was made by scanning, the dominant size driver is the scan resolution. A 600 DPI scan is roughly 16× the data of a 150 DPI scan. For most non-archival uses, 200–300 DPI is more than enough. Rescanning at the right DPI is a bigger win than any compression algorithm.

Round-trip through images. PDF to Images at moderate JPEG quality, then Images to PDF, produces a fully image-based PDF that is often dramatically smaller than the original. The trade-off: you lose any selectable text — the result is just pictures of pages. Useful for distribution copies, not for the master version.

Split and compress separately. Some PDFs have a few very large pages that drag the average up. Use Split PDF to break the file into chunks, find the bloated pages, and compress those separately or replace them with cleaner versions.

Strip embedded files. Some PDFs ship with attached spreadsheets, original Word files, or other embedded content that travels invisibly with them. Re-exporting through any modern PDF editor strips this without affecting the visible content.

Privacy Note

Compression runs on PDFwarp's servers and the file is deleted immediately after you download the result. No AI services or third parties see the document. See the Privacy Policy for the full data flow.

The Bottom Line

A PDF that refuses to compress is usually not a broken file or a broken tool — it is a file whose easy savings have already been claimed. Modern document tools produce already-optimized output, and there is a real floor below which no compressor can shrink a typical document without visibly damaging it.

The right approach is to know which kind of PDF you have, pick the level that matches it, and accept that text-heavy documents will not shrink the way image-heavy ones do. Use the preview to confirm before committing, and use the right tool — rescanning, splitting, or round-tripping through images — for the rare files that genuinely need an extreme reduction.

If you have ever clicked Compress expecting 50% and gotten 3%, the answer is almost always that 3% is what your file had to give.