A PDF with ten pages of text should be tiny. So why does your scanner produce a 40 MB file? And how does a compressor shrink it to 4 MB without visibly changing anything? Here's what's actually happening — and how modern browsers can now do it without sending your file anywhere.
Why PDFs get large
A PDF is not a single blob of data — it's a structured container holding several types of content:
- Raster images — scanned pages, embedded photos, screenshots. These are the biggest culprit. A scanned A4 page at 300 DPI produces a roughly 2,480 × 3,508 pixel image. At 8 bits per channel, that's about 26 MB of raw data per page before any encoding.
- Fonts — PDFs embed font files to ensure the document looks identical everywhere. A single font can be 200–500 KB. Documents using many different fonts balloon quickly.
- Vector graphics — charts, logos, and diagrams stored as paths. These are usually small but can be verbose if exported naively.
- Metadata and structure — cross-reference tables, bookmarks, annotations, and XMP metadata. Minor contributors but cleanable.
Most inflated PDFs are dominated by images — particularly scanned documents where the source resolution was set unnecessarily high, or where images weren't re-encoded before embedding.
What compression actually changes
There are two fundamentally different approaches a PDF compressor can take:
Lossless compression
Re-encodes streams using more efficient algorithms (Flate/zlib). No quality loss whatsoever. Savings are typically small — 5–20%. Good for text-heavy PDFs.
Lossy compression
Downsamples and re-encodes images at a lower resolution or higher JPEG compression ratio. Savings of 40–85% are common. The right choice for scanned documents.
Most real-world compression tools — including Ghostscript — use both: lossless re-encoding for text and vector streams, and configurable lossy compression for images. The quality preset you choose controls how aggressively images are downsampled.
DPI: the biggest lever for image-heavy PDFs
DPI (dots per inch) controls image resolution. For screen viewing, 72–96 DPI is indistinguishable from 300 DPI. For print, 150–300 DPI is needed. For archival quality, 300–600 DPI is standard.
| Preset | Target DPI | Best for |
|---|---|---|
| Small | 72 DPI | Screen viewing, email attachments |
| Balanced | 150 DPI | Most uses — sharp on screen, acceptable in print |
| High Quality | 300 DPI | Print-ready output |
These correspond to Ghostscript's /screen, /ebook, and /printer PDFSETTINGS presets — the same options used by professional print workflows.
Ghostscript: the engine behind professional PDF compression
Ghostscript is a 35-year-old open-source interpreter for the PostScript and PDF languages. It's used in professional print workflows, server-side document processing pipelines, and — increasingly — in browser-based PDF tools.
When Ghostscript compresses a PDF, it doesn't just re-encode streams. It fully interprets the PDF (renders it into an internal representation) and then re-writes it from scratch with optimised settings. This is why it achieves better results than tools that merely re-encode streams without understanding the document structure.
WebAssembly: native speed inside the browser
WebAssembly (WASM) is a binary instruction format designed to run at near-native speed in any modern browser. It was standardised by W3C in 2019 and is now supported in Chrome, Firefox, Safari, and Edge.
Crucially, WASM lets developers compile existing native applications — written in C, C++, or Rust — directly to a format the browser can execute. Ghostscript is written in C. By compiling it to WebAssembly, the entire Ghostscript engine runs inside your browser tab, with no server involved.
How LocalDF uses it: When you compress a PDF, the browser loads a ~10 MB WebAssembly binary (Ghostscript). This binary runs inside a Web Worker — a background thread that doesn't freeze the UI. Your file is passed to it in memory, processed, and the result returned to the page for download. Nothing leaves your browser.
Performance: is it slower than server-side?
For typical PDFs (under 20 MB), browser-based compression with Ghostscript WASM takes 5–15 seconds on a modern device. Server-side tools appear faster because they show a spinner while the upload travels over the network — the actual processing time on their end is similar.
On older devices or very large files, browser-side processing will be slower. For files over 50 MB, a server-side tool may be the pragmatic choice — just be aware of the privacy trade-off.
What can't be compressed further?
Some PDFs won't shrink much, regardless of the tool:
- PDFs that already contain highly compressed JPEG images at low resolution
- Text-only PDFs (compression gains are limited to metadata and stream encoding)
- PDFs with embedded video or audio
- Password-protected PDFs with strong encryption
If a PDF is already at or near its theoretical minimum size, no compressor can make it meaningfully smaller — they're just re-encoding already-compressed data.
See it in action
Try LocalDF's browser-based compressor. Uses the same Ghostscript engine described above — running locally in your browser, with no upload required.
Compress a PDF now →