I Compressed 100 PDFs to Find the Sweet Spot — Here's the Data

I have a confession: I spent three weekends compressing the same documents over and over again with different tools and different settings, tracking file sizes in a spreadsheet that my partner now calls "the nerd sheet." This started because our team was emailing around 40+ MB presentation decks and consistently hitting Gmail's attachment limit. I wanted a real answer — not a blog post that just says "use 'medium' compression" — so I ran the numbers myself.

Here is what I actually found.

The Test Setup

I gathered 100 PDFs across five categories:

• Scanned documents (25 files) — old contracts, paper forms run through a flatbed scanner at 300 DPI, average original size 8.4 MB
• Presentation decks (20 files) — exported from Google Slides and PowerPoint, heavy on PNG illustrations and gradients, average 14.2 MB
• Reports with mixed content (20 files) — Word-to-PDF exports with embedded charts, tables, and a few photographs, average 3.1 MB
• Photo-heavy PDFs (15 files) — product catalogs and real estate brochures, average 22.7 MB
• Text-only documents (20 files) — contracts, terms of service, plain typography, average 0.4 MB

I ran each file through three compression tiers: low (targeting visual losslessness), medium (the default most tools ship with), and high (maximum size reduction). I also tested split operations on the larger files to see whether splitting before compressing made any practical difference. All quality assessments were done by opening the compressed output at 150% zoom and checking whether text remained crisp and whether photos looked obviously degraded.

The Results, Category by Category

Scanned Documents: The Biggest Wins

This is where compression earns its keep. Scanned PDFs are notoriously bloated because scanners embed images at full resolution with minimal optimization. Across my 25 scanned files:

• Low compression: average reduction of 38%, quality indistinguishable from original
• Medium compression: average reduction of 67%, quality good for screen reading, slight softening visible at 200%+ zoom
• High compression: average reduction of 81%, clearly degraded — text in small fonts became blurry, stamps and signatures looked smudged

The sweet spot for scanned documents is unambiguously medium. An 8.4 MB scanned contract goes down to about 2.8 MB, which is perfectly legible for archiving and email, and you lose nothing meaningful. High compression crossed a line I would not want to cross for anything legal or official — a blurred signature is a problem waiting to happen.

Presentation Decks: Where It Gets Complicated

Presentations were the most frustrating category. The results were inconsistent, and the reason became clear once I dug into it: compression tools handle PNG illustrations and JPEG photos very differently.

• Low compression: average reduction of only 12% — essentially useless for this format
• Medium compression: average reduction of 44%, but quality variance was high — slides with flat-color illustrations came out fine; slides with photographic backgrounds showed JPEG artifacts
• High compression: average reduction of 71%, but six out of twenty decks looked genuinely bad — gradient backgrounds banded, photos went muddy

My actual recommendation for presentations: compress at medium, then spot-check the first three slides. If your deck is icon-heavy with flat colors, you will be fine. If it has full-bleed photography, you may need to manually re-export those specific pages at higher quality from the source application instead of blanket-compressing the whole PDF.

Mixed Reports: The Reliable Middle Ground

Word-to-PDF exports with embedded charts performed most predictably:

• Low compression: 22% reduction
• Medium compression: 51% reduction, zero visible quality loss in any of the 20 files
• High compression: 63% reduction, minor softening in photographic images but charts and text remained sharp

For reports, you can push to high compression without regret if the document does not contain photographs. The difference between medium and high is modest in absolute terms (3.1 MB → 1.5 MB vs. 3.1 MB → 1.1 MB), so unless every kilobyte matters, medium is good enough and has zero risk.

Photo-Heavy Catalogs: Manage Your Expectations

This is the category where people tend to get disappointed. A 22 MB product catalog contains enormous amounts of photographic data, and there is a real ceiling to how much you can remove before it looks bad.

• Low compression: 19% reduction — barely worth running
• Medium compression: 47% reduction, acceptable for digital sharing but not print
• High compression: 73% reduction, consistently unacceptable — color banding, texture loss, the kind of thing a client notices immediately

The honest answer for photo-heavy PDFs is that medium compression is the ceiling you should use, and even then you should evaluate whether the output meets your quality bar for the specific use case. For print: never compress. For a sales email or a website download: medium is fine. For archiving the master copy: compress nothing.

Text-Only Documents: Barely Worth Compressing

The 0.4 MB average starting size tells you everything. Medium compression brought these down to 0.28 MB on average. That is 120 KB saved on a file that already fits in an email with room to spare. Unless you are processing thousands of them in bulk, compression adds no meaningful value here.

One thing I did notice: running high compression on text-heavy PDFs occasionally introduced subtle font rendering changes — not degradation exactly, but the character shapes looked fractionally different when printed. I am not sure exactly what caused this (possibly font subsetting behavior), but it was consistent enough that I would leave text-only PDFs alone entirely.

Does Splitting Before Compressing Help?

I tested this specifically on the 15 photo-heavy catalogs, splitting each into individual pages, compressing each page PDF, then recombining. The theory was that per-page compression might be more targeted.

The results: no meaningful difference. Average total size was within 2% of compressing the whole document at once. The extra steps — split, compress each, merge — took about four times as long with no payoff. The only scenario where splitting genuinely helped was when one section of a document (say, a 30-page report with a 10-page appendix of scanned attachments) needed different compression levels. Splitting let me apply medium to the main body and low to the scanned appendix, giving better quality on the problematic pages while still reducing overall size.

That targeted approach — split by content type, compress each section differently, recombine — is genuinely useful. Blanket splitting every page is not.

The Actual Sweet Spot Table

A Few Things I Did Not Expect

Some findings genuinely surprised me. First: the tool matters more than the compression level label. "Medium" in one tool matched "high" in another when I compared output sizes. The label is relative to each tool's own scale, not an industry standard. When evaluating any PDF compressor, run your own baseline test with a representative file before committing to a workflow.

Second: file size after compression is not perfectly correlated with quality degradation. Some files I compressed to 30% of original size still looked excellent; others at 60% of original showed artifacts. The original file's internal structure — how images were encoded when the PDF was created — matters enormously. A PDF with images already saved as high-quality JPEGs will degrade faster under compression than one with PNG images being converted to JPEG for the first time.

Third: page extraction (splitting out specific pages) consistently produced smaller per-page files than full-document compression when those pages were image-light. Extracting your cover page and first five pages of a proposal to send as a preview PDF is a smarter move than compressing the whole 60-page document and hoping for the best.

The Bottom Line

If I had to give one universal setting to a colleague who does not want to think about this: use medium compression for everything that has images, skip compression for pure text. You will hit 44–67% reduction on the files that actually need it and avoid the quality surprises that come with pushing to maximum. For documents that need to survive print or close scrutiny, do a 30-second visual check of the output before sending — that one habit catches problems before they become embarrassing.

The "nerd sheet" is available if anyone wants the raw numbers. I am only slightly joking.