An 18 MB scanned contract shrank to 234 KB in a browser tab. The same file, fed to desktop Ghostscript, only made it down to 4.5 MB. But a 126-page tax booklet grew by 7% in the browser while Ghostscript cut it by 31%. PDF compression is not one problem, and after running fifteen timed tests I finally understand why the same tool can feel like magic on one file and useless on another.

Here is the whole experiment: five PDFs, three compression levels in a browser, two Ghostscript presets on the same machine, plus a forensic check of every output file to see what actually survived.

Try Compress PDF: free, no sign-up.

The setup: five files, two compressors, no mercy

I wanted files that represent what people actually try to compress, not marketing demos. Four archetypes, five files:

Form 1040 (the real IRS PDF): 215 KB, 2 pages, pure vector text.
Form W-4 (also the real IRS PDF): 209 KB, 5 pages.
The 1040 instruction booklet: 4.3 MB, 126 pages of dense text with charts.
A scanned-contract style PDF: 17.9 MB, 8 pages. I generated this one myself at 300 DPI with realistic scanner noise, because I needed a known-clean scan I had rights to.
A photo-style PDF: 366 KB, 6 pages of image content (also generated, gradient-and-shape pages that behave like photos).

The browser side was the free Compress PDF tool on this site, which runs entirely client-side: the file never leaves your machine. It offers four levels, and I used three of them (Lossless, Strong at 110 DPI, Extreme at 80 DPI).

The desktop side was Ghostscript 10.05, the console utility most "optimize PDF" tutorials tell you to install. I ran its two standard shrink presets, /ebook and /screen.

Everything ran on the same Windows machine. Browser timings are end-to-end (page load included). Now the numbers.

The headline results, file by file

Key takeaway: scans collapse, born-digital text files refuse to shrink, and the tool tells you when it can't help.

The scanned contract, 17.9 MB:

Browser, Lossless: 17.9 MB (0.0% saved)
Browser, Strong (110 DPI): 657 KB, 96.3% smaller
Browser, Extreme (80 DPI): 234 KB, 98.7% smaller
Ghostscript /ebook: 1.8 MB (89.8% smaller)
Ghostscript /screen: 4.5 MB (74.6% smaller)

That last line is not a typo. Ghostscript's most aggressive preset did 19 times worse than the browser's Extreme mode on this scan. Downsampling noise-heavy scans to 72 DPI and re-encoding them the way Ghostscript does actually costs more bytes per pixel of detail than a clean 80 DPI JPEG rebuild.

The photo-style PDF, 366 KB:

Browser, Strong: 166 KB (54.6% smaller)
Browser, Extreme: 96 KB (73.8% smaller)
Ghostscript /screen: 122 KB (66.5% smaller)

The browser wins again, by about 22%.

Now the painful half of the story. The 126-page booklet, 4.3 MB:

Browser, every mode: grew to 4.6 MB, a 7% increase
Ghostscript /ebook: 3.0 MB (30.9% smaller)

And Form 1040, 215 KB:

Browser, Lossless and Strong: grew 0.9%
Browser, Extreme: 203 KB (5.7% smaller)
Ghostscript: I'll be honest, I stopped counting pennies on a 215 KB file. If your problem is a 215 KB file, you don't have a problem.

The W-4 grew 2.2% in the browser no matter what I did. Every single "bigger file" result came with a plain-language note in the result card saying the file was already well structured and couldn't be compressed further without quality loss. No silent bait-and-switch, no pretending. I checked the output bytes: the warning was accurate every time.

Why a scan can shrink 98.7% and a booklet can't

This is the part nobody explains, and it took building the test files to really see it.

A 300 DPI scan stores roughly 8.5 million pixels per letter page. Almost all of them are near-white paper with faint noise. When the browser's Strong mode kicks in, it re-renders each page at 110 DPI and re-encodes it as a fresh JPEG at quality 62. You go from 8.5 million noisy pixels to about 1.1 million clean ones. The noise, which is exactly the stuff JPEG struggles with, gets smoothed away. That is where the 96% comes from.

Key takeaway: compression size gains come from throwing away pixels, not from squeezing text.

A born-digital booklet is the opposite. Its pages are already vector instructions: "draw this glyph here, this line there." Those instructions are tiny. The 4.3 MB is mostly embedded fonts and a few raster charts, already compressed by the IRS's own publishing pipeline. There is no pixel sea to drain.

The browser's lossless pass can only repack the file's object structure, and the booklet's structure was already packed. Repacking added 300 KB of overhead. That is the 7% growth, and it is honest physics, not a bug.

Ghostscript wins on the booklet because it is willing to do things a browser tool (rightly) refuses: it re-encodes embedded images, subsets fonts down to the glyphs actually used, and strips duplicate resources. On a 126-page government document with repeated headers and fonts, that recovers real space. It also needs a command line and it rewrites your file structure while doing it.

The fallback I didn't expect

Here's a behavior worth knowing if you use the compress tool: Strong and Extreme are not guarantees, they're attempts.

When I ran Strong on the W-4, the tool rasterized the pages, saw that the JPEG rebuild would be bigger than the original, and quietly fell back to the lossless pass instead of handing me a worse file. I only noticed because the result note described the lossless behavior and my byte counts matched the lossless output exactly.

The cutoff is a 5% gain. If rasterizing won't beat your original by at least that much, you get the structural pass and an honest note. On real-world files this fallback fired on 4 of my 15 runs.

Does the text survive? I extracted it to find out

Size is worthless if the output is a husk. After every run, I pulled the downloaded file apart.

First, page counts. Every single output had exactly the page count of its input: 8 and 8, 6 and 6, 126 and 126. No dropped pages in any mode.

Then text extraction, the honest test of "is this still a real PDF." I ran a text extractor over every output:

W-4, lossless output: 20,948 characters of extractable text
Form 1040, lossless output: 7,930 characters
Booklet, lossless output: 495,397 characters
Every Strong and Extreme output: zero extractable text

That last line is the trade-off in one number. Raster modes convert pages to images, so text is visible to your eyes but gone to any machine: no selecting, no copying, no Ctrl+F, no screen readers. Lossless keeps everything selectable.

Key takeaway: if you need to search or copy from the document later, stay lossless. If it just needs to be readable and small, Strong is the sweet spot.

And if you rasterize something and then need its text back, don't retype it: run it through PDF to Word conversion first, edit, then compress what you must.

Speed: the browser is not the slow option anymore

Old advice says desktop tools are faster. Not what I measured.

The 17.9 MB scan through the browser's Strong mode took about 5 seconds end-to-end, Extreme about 4 seconds, and that includes loading the page. The 126-page booklet at Strong took around 18 seconds total, worst case in the whole batch, again with page load and ads in the timer.

Ghostscript's /ebook pass on the booklet wasn't instant either, and it's a fair trade: Ghostscript buys better booklet compression with slower, more invasive processing plus a install-and-learn-command-flags tax. For a file you need shrunk once, the browser is the faster path to a good enough result, and for scans it's the faster path to a better result.

An accidental error-path test

My first download of the W-2 from the IRS website was silently blocked: the server returned an HTML page, and I saved it with a .pdf extension without noticing. The browser tool refused it instantly with a "No PDF header found" parse error instead of producing garbage. A minute of my own debugging confirmed the file genuinely wasn't a PDF.

I consider that a pass. Compression tools earn trust by failing loudly, not by succeeding fictional files.

Which tool should you actually use?

After fifteen runs, my decision tree, with no hedging:

Scanned document, need it small and readable: browser, Strong (110 DPI). 96% off is normal; text is no longer selectable, which for a scan you're archiving or emailing is usually fine.
Scanned document going to a chat app with a hard size cap: browser, Extreme. 98.7% off. Read it on a phone without squinting; don't print it.
Born-digital text PDF (tax forms, invoices, papers): don't bother. If it's already under a couple of MB, compression has nothing to give you. If a form-based PDF is somehow huge, it's image-laden, so treat it like a scan and use Strong.
Mixed booklet with charts you must shrink for real: a desktop tool with font subsetting (Ghostscript /ebook) is the one case desktop wins, and it's worth the command line only for files in the multiple-MB range.
PDF that must stay searchable and selectable: lossless only, accept that savings may be zero, and if there's a size cap you're stuck against, the honest fix is splitting the document, not mangling it. Splitting a PDF into chapters beats crushing it into pixel mush.

Everything I used is free and in-browser on the PDF tools hub. I ran an earlier round of compression tests a while back with a smaller toolbox; the strong raster modes tested here are what changed the game for scans. And if you're merging a batch of single-page scans before compressing, merge them first, then run Strong once.

FAQ

Is compressing a PDF in my browser safe?

With a client-side tool, yes: the file is processed by JavaScript on your device and never uploaded. Close the tab and it's gone. That's the main argument for browser compression over random "free online PDF compressor" sites, many of which upload your document to servers in countries you can't spell.

Why did my PDF get BIGGER after compression?

It was almost certainly a born-digital text PDF (exported from Word, filled in a tax program, downloaded from a bank). Those files are already optimally structured, so repacking adds slight overhead. A good tool tells you this happened instead of claiming success. Scans and image-heavy files are where big savings live.

What DPI should I pick for a scanned document?

110 DPI (Strong) for anything you'll read on a screen: my 300 DPI scan kept full readability at 96% size reduction. Use 80 DPI (Extreme) only for chat-app sharing and phone reading. Print targets want 144 DPI (Light) or better.

Will a compressed PDF still print fine?

Lossless: identical printing, always. Light (144 DPI): fine on a home printer. Strong (110 DPI): readable but noticeably soft on paper. Extreme (80 DPI): screen only, do not print.

Browser or Ghostscript, which one wins?

For scans and photo PDFs, the browser, and it's not close (234 KB vs 4.5 MB on my test scan). For text-and-chart booklets in the multi-MB range, Ghostscript /ebook and its font subsetting win by roughly a third. Browsers can't safely subset fonts in a client-side tool, so that gap is structural, not a matter of waiting for faster JavaScript.