Measured, not estimated
PDF Compression Levels Compared
Published Last reviewed
The compressor offers three levels: High Quality, Balanced, and Smallest Size. Their names suggest a simple ordering from largest to smallest output. The measurements below show that the ordering does not always hold, and explain why.
Every figure on this page comes from running 9 generated test documents through the same engine and the same settings this site uses, then reading the resulting file sizes. Nothing here is estimated.
The test documents are generated from fixed seeds, so a rebuild produces byte-identical inputs on any machine. From a checkout of the source repository:
node benchmark/build-corpus.mjs
node benchmark/run-benchmark.mjsEngine: GPL Ghostscript 9.56.0, invoked with the same arguments as the browser worker that runs on this site.
What each level does to an image
The levels map onto Ghostscript PDFSETTINGS presets. Rather than restate the documented target resolutions, the table below reports what actually came out of a three-page 300 dpi grayscale scan: the pixel dimensions of the largest image in each output, and the compression filter applied to it.
| Level | Preset | Largest image | Filter | Image stream |
|---|---|---|---|---|
| High Quality | /printer | 2480 by 3508 | DCTDecode | 670.1 KB |
| Balanced | /ebook | 1240 by 1754 | DCTDecode | 273.6 KB |
| Smallest Size | /screen | 595 by 842 | FlateDecode | 361.0 KB |
Each step down halves the pixel dimensions. The filter column is where the surprise lives, and the next section returns to it.
Results across 9 documents
Each document isolates one mechanism rather than representing an average file. Not smaller means the engine produced an output at least as large as the input; the live tool reports those as a failure and offers no download, so no percentage is shown.
| Document | Original | High Quality | Balanced | Smallest Size |
|---|---|---|---|---|
| 300 dpi grayscale scan, 3 pages | 5.98 MB | 1.92 MB−67.9% | 809.1 KB−86.8% | 1.05 MB−82.5% |
| Illustrated report, 6 pages | 1.25 MB | not smaller | not smaller | 78.3 KB−93.9% |
| Text-only document, raw streams | 39.4 KB | 20.1 KB−48.8% | 16.7 KB−57.5% | 16.8 KB−57.2% |
| Presentation export, 8 slides | 3.60 MB | not smaller | not smaller | 173.4 KB−95.3% |
| Interactive AcroForm, 2 pages | 3.43 KB | not smaller | not smaller | not smaller |
| Transparency and blend modes, 4 pages | 47.6 KB | 27.3 KB−42.6% | 24.3 KB−48.9% | 24.4 KB−48.8% |
| Already-optimised document, 6 pages | 78.3 KB | not smaller | 78.3 KB−0.0% | not smaller |
| Repeated figure, 10 pages | 2.62 MB | 283.6 KB−89.4% | 277.6 KB−89.6% | 15.9 KB−99.4% |
| Text-only document, compressed streams | 8.13 KB | not smaller | not smaller | not smaller |
Smallest Size is not always the smallest
On the 300 dpi scan, Smallest Size reduces the image to a quarter of the pixels that Balanced keeps, yet produces a larger file: 809.1 KB at Balanced against 1.05 MB at Smallest Size.
The filter column above explains it. Balanced keeps the image as JPEG (DCTDecode). Smallest Size stores it with FlateDecode, a lossless method that is efficient for flat graphics and line art but poorly suited to the continuous tones of a scanned page. Fewer pixels, stored far less efficiently, adds up to a bigger file.
This affected 4 of 9 documents in this set. The practical consequence is simple: when a file needs to be as small as possible, try Balanced as well as Smallest Size and compare the two results. The stronger-sounding level is not guaranteed to win.
Compression can make a file larger
A small document has little to gain and a fixed amount to lose. The interactive acroform, 2 pages in this set starts at 3.43 KB and grows at every level, reaching 6.88 KB at Smallest Size and 9.54 KB at High Quality. The structural information the engine writes on its way out exceeds the entire original file.
The same happens when a document has already been compressed. There is no reserve of removable data left, so a second pass mostly adds overhead. In both cases the tool refuses the result rather than presenting a larger file as a success. The measured reasons a PDF will not compress covers this in full, including why an ordinary text document more than doubles in size.
What changes besides the file size
Compression rewrites the document rather than editing it. Page count survived intact across every document tested, but two structural changes are worth knowing about before compressing something important.
Interactive form fields do not survive. The interactive acroform, 2 pages went in with a fillable form definition and came out without one. If a PDF has fields people are meant to type into, compressing it here will cost that functionality. Keep the original.
Repeated images are merged. A document storing one figure as 10 separate objects came out with 1, a reduction of 89.6% at Balanced with no downsampling involved at all. Documents that reuse a logo or letterhead on every page benefit from this even when their images are already well compressed.
Other elements — annotations, attachments, layers, and scripts — may also be altered. The Terms of Use state these limits, and encrypted or digitally signed PDFs are rejected before compression rather than silently damaged.
Choosing a level
Start with Balanced. It produced the smallest usable output on more documents in this set than either alternative, and it keeps photographic content in a format suited to it.
Use Smallest Size when a hard limit demands it, then compare it against the Balanced result rather than assuming it wins. On documents whose images sit well above their displayed size, it is dramatically more effective; on scans it can go the wrong way.
Use High Quality when the document will be inspected closely. On several documents it produced no usable reduction at all, which is the honest outcome when the images are already at or below the level target.
Whichever level you choose, open the downloaded file and check the pages that matter before discarding the original. Compress a PDF now.
How these numbers were produced
The documents are generated programmatically from fixed seeds rather than collected, so the exact inputs behind every figure can be rebuilt by anyone. The harness loads the same WebAssembly build of GPL Ghostscript 9.56.0 that this site serves to browsers, and a test asserts that its argument list matches the worker in production, so the published numbers cannot silently drift away from the shipped tool.
Several limits bound what these figures mean:
- The text document appears twice on purpose. One copy leaves its content streams uncompressed and one compresses them, because every real exporter compresses. The uncompressed copy reports a large reduction that no genuine document would see; the compressed copy cannot be reduced at all. Read the pair together rather than either number alone.
- Fonts are not embedded. The text documents use standard base-14 fonts, so font subsetting has nothing to remove. Real documents embed fonts and may gain there.
- Images are synthetic. They are generated gradients with grain, not photographs. Absolute ratios for image-heavy cases are indicative rather than predictive.
- One document per case. These isolate mechanisms; they are not a statistical sample of real-world PDFs.
The preset behaviour described here is documented by Ghostscript, and the implementation is public. Both are listed on the Source Code page. If a figure looks wrong or the tool behaves differently for you, the Contact page is the place to report it.