"PDF Compression Tested: 5 Files, 4 Modes, Surprising Results"

Every PDF compression guide tells you the same thing: "results vary." That is technically true and completely useless when you are staring at a 25 MB scan that an email server refuses.

So I ran an actual test. I took five PDFs that represent what people actually try to compress, fed each one through a free browser-based PDF compressor in every mode it offers, and recorded the exact before-and-after sizes. No vendor claims, no rounding up. The spread between the best and worst result was bigger than I expected, and the pattern behind it is consistent enough to predict how your own file will behave.

Try Compress PDF: free, no sign-up.

The five test files

Not all PDFs are alike, and compression methods that work beautifully on one type can do almost nothing to another. Here is what went into the test:

• A 14-page academic paper (992 KB). Real published paper, text and vector graphics, no photos. This is what "normal PDF" means to most people.
• An image-heavy mixed document (1.43 MB). Pages built around embedded raster images with some text on top. Think marketing deck exported to PDF.
• A photo page (365 KB). A single page dominated by one high-resolution JPEG image.
• A small mixed file (9 KB). Tiny to begin with. Tests whether compression can shrink something that is already lean.
• A vector-only file (34 KB). Pure text and line drawings, zero embedded images.

The tool offers four modes, and I tested the two ends of the spectrum plus the default:

• Lossless. Repacks the file structure. Text stays selectable. The default and the safest option.
• Light (144 DPI), Strong (110 DPI), Extreme (80 DPI). These rasterize pages: each page becomes a JPEG image at a fixed resolution. Text stops being selectable, but image-heavy files shrink dramatically.

All processing happens in the browser, which matters for privacy since nothing gets uploaded anywhere. Each run was timed from click to finished download.

The results table

Read this one slowly, because two numbers in it contradict what most guides claim:

Every single compression finished in about two seconds. The speed is not the story here. The pattern is.

Finding 1: lossless mode cannot touch embedded images

The tool's honest default saved 5.3% on the academic paper, and that was its best performance of the day. On the image-heavy files it managed 0.1% to 0.5%, which rounds to nothing.

This is not a tool flaw. It is how lossless PDF compression works everywhere, including desktop software costing hundreds per year. A JPEG embedded in a PDF is already compressed. Repacking the surrounding structure saves bytes on fonts, duplicate objects, and cross-reference tables, and a photo has none of that slack. The math is unforgiving: there is simply nothing left to squeeze without re-encoding the images themselves.

If your PDF is mostly photos or scans and someone tells you their tool "compresses up to 90% losslessly," they are describing a file type you do not have.

A quick tour of what is actually inside a PDF

To predict your own result, it helps to know what a PDF contains. Every page is a small program that draws things:

• Text objects. References to embedded font files plus the character codes to draw. Compresses well because fonts are often stored inefficiently, and duplicate font subsets can be merged.
• Vector graphics. Lines and curves described as coordinates. Extremely compact by nature. A page of pure vector art might be 3 KB.
• Raster images. Raw pixel data, almost always already JPEG or JPEG-2000 compressed inside the file. This is where the bulk of the bytes live in scans and photo documents, and lossless passes cannot legally touch them without quality loss.
• Structural overhead. Cross-reference tables, object streams, metadata, revision history appended by every editor that ever touched the file.

Lossless mode works on the fourth category and tidies the first. That is why our clean academic paper lost 5.3% while the photo page lost 0.5%. The photo page was 95%+ category three.

There is a bonus insight hiding in that list: PDFs that have been edited repeatedly often carry orphaned objects from earlier revisions. If your 40-page document is mysteriously 8 MB, an appended revision history from three rounds of comments might be a third of it. A lossless repack strips that dead weight, which is why some users see 25-30% savings on text PDFs and think the tool is magic. It is not magic; the file was just carrying luggage.

Finding 2: rasterize mode is a different tool wearing the same name

The Extreme mode results look like a typo until you understand what actually happens. The 1.43 MB image document became 15 KB. Ninety-nine percent gone.

The mechanism: every page gets re-rendered as an 80 DPI JPEG at quality 45 and the file is rebuilt from those images. For on-screen reading and chat-app sharing, 80 DPI is rough but legible. For anything else, it is a trade, and the tool says so plainly in its result message: pages become images, text is no longer selectable, and the file tells you exactly what was done to it.

That honesty matters. The other mode names on the spectrum (Light at 144 DPI, Strong at 110 DPI) exist because 80 DPI is not always the right answer. A rental application you need to email is a different use case than a receipt you are archiving.

The DPI ladder, decoded

Dots per inch determines how many pixels each page becomes, and pixel count is the single biggest driver of file size. Here is the ladder in practical terms:

• 144 DPI (Light). A US Letter page becomes 1224 x 1584 pixels. Text is crisp, images keep most of their detail. Savings on image files: solid double digits, usually 40-70%.
• 110 DPI (Strong). The everyman setting. Comfortable to read on a laptop or tablet. This is where scans typically land after a 70-90% cut.
• 80 DPI (Extreme). Built for one job: getting under a hard upload limit. Chat apps, web forms with a 100 KB cap, email systems with aggressive filters.

A useful mental model: halving the DPI quarters the pixels. A page at 144 DPI has about 3.2 times the pixels of the same page at 80 DPI, which is why the jump from Light to Extreme is so violent in the results table.

One caution from the test: DPI trades badly against text sharpness on small mixed files. Our 9 KB file dropped to 2 KB at Extreme, which sounds great until you realize a 7 KB saving is meaningless and the text is now fuzzier. Percentage alone is a bad decision metric on small files.

Finding 3: the tool refuses to make your file worse

Here is the detail I appreciated most. On the academic paper, I explicitly selected Extreme mode. The tool ran its rasterize pass, saw that rebuilding the text pages as JPEGs would save less than a lossless repack (or destroy selectable text for almost no gain), and quietly delivered the lossless result instead: 940 KB, text intact, with the reason stated in the result line.

Most compression tools either refuse to run or blindly follow instructions. Guardrails that quietly prevent a bad outcome, with an explanation attached, are rare. The rule of thumb the tool enforces: if rasterizing gains less than about 5%, it falls back to lossless.

This behavior answers a question people ask constantly: "why did my file barely shrink even on the strongest mode?" Because the tool checked whether the strong mode would actually help, found it would not, and protected the text instead. A tool that silently degraded your searchable document to save 2% would be worse than useless.

Which mode should you actually use?

After watching every combination run, the decision tree is simple:

• Text documents, forms, anything with selectable text you need to keep: Lossless. Expect 5-30% off. If it is mostly clean text, you get the high end.
• Scans and photo-heavy files you need to shrink hard: go straight to a rasterize mode. Try Strong (110 DPI) first; drop to Extreme only if you need the last few percent for an upload limit.
• Files under ~50 KB: do not bother. Savings are absolute, not relative, and a 7% cut of 9 KB is under one kilobyte.
• Anything you must keep searchable or archivable: stay lossless, accept the modest savings, and consider splitting the document instead.

Two neighbors in your toolbox if compression alone does not get you under a limit: merge PDF files to control what goes in, or rotate and fix pages before you commit to a rebuild.

The batch strategy the numbers suggest

Here is the workflow I would use for a real pile of documents, based on how the modes actually behaved:

Run everything through lossless first, as a batch. It costs nothing in quality, takes about two seconds a file, and harvests all the free structural savings. Anything that is text-heavy lands 5-30% smaller and you are done with it.

Then look at what is left. The files still over your limit are, almost by definition, the image-heavy ones. Those get a second pass at Strong (110 DPI). Check the result, and only the stubborn few get Extreme.

The mistake to avoid is batching everything at Extreme from the start. It feels efficient, and it silently costs you every searchable document in the pile. Since the fallback protection only kicks in when rasterizing gains under about 5%, a text document with a handful of embedded logos could clear that bar, get rebuilt as images, and lose its selectable text forever. Nobody warns you at the time; you find out a month later when search returns nothing.

One more practical note from the test runs: rerunning the same file through the same mode produced byte-identical results, so there is no "roll the dice again" benefit to repeated passes. But running lossless first and then rasterizing the output can compound savings slightly, because the rasterizer rebuilds from a tidier starting file. The gains are small, single-digit percent, so treat it as a last resort rather than a strategy.

Why browser-side compression is the quiet winner here

Every test above ran with zero uploads. The file never left the machine it was on. For tax documents, medical records, or anything with a Social Security number on it, that is the entire ballgame, and it is why the two-second timing matters: nothing is being shipped to a server, queued, processed, and downloaded back.

The same privacy logic applies to editing PDF text and every other tool in the PDF toolkit. Client-side processing is not a compromise anymore. WebAssembly made it the fastest and safest default.

The one-line summary

Match the mode to the file: lossless for text, rasterize for scans, and skip compression entirely on tiny files. And when a tool reports its savings honestly, down to the kilobyte, believe the number it gives you over any percentage a landing page promises.

FAQ

Why did lossless mode only save 0.1% on my image PDF? Because embedded JPEGs are already compressed, and lossless mode deliberately does not re-encode them. It repacks file structure only. Files dominated by photos have almost no structural slack, so savings round to zero. Use a rasterize mode for those files.

Does Extreme mode ruin the quality? It renders every page at 80 DPI as a quality-45 JPEG. For screen reading and chat sharing that is usually fine, and it cut our 1.43 MB test file to 15 KB. But fine text becomes fuzzy and nothing is selectable afterwards. Try Strong (110 DPI) first if you care about legibility.

Will the text stay selectable after compressing? In lossless mode, always. In the rasterize modes, never, because pages become images. If you need to search or copy text later, stay lossless.

How long does it take? About two seconds per file in our tests, regardless of mode, because everything runs locally in your browser rather than uploading to a server queue.

Is it safe for confidential documents? Yes. The tool runs entirely client-side using WebAssembly. Your file is never uploaded, so there is no server copy, no retention policy, and nothing to breach.