PDF compression benchmark

What this does and does not establish

Read this before the numbers, because it determines what they are worth.

• The corpus is synthetic. Every test document is generated by a seeded script, not taken from real work. That is a deliberate trade: real documents would be more representative and impossible for anyone else to verify, because nobody else can have the files. These can be rebuilt byte-for-byte by anyone.
• Export settings were chosen to match real software, not to flatter the result — scans at about 200 DPI and JPEG quality 80, designed pages at quality 85. An earlier draft of this corpus used quality 95 with chroma subsampling disabled, which nothing in the world actually emits, and which made the reductions look roughly twice as good as they are.
• These figures are not a prediction about your file. They establish the mechanism and the order of magnitude. A document whose images are already sized correctly for the page will save far less than one where a 12-megapixel photograph was dropped into a thumbnail frame.
• One machine, one browser. Times are from headless Chromium on a Linux server. A phone will be slower, and how much slower depends on the device.

Method

Each document was loaded into a page running the same compress-engine.js that the live Compress PDF tool uses, at the same two non-destructive settings the tool offers. Each case was run three times and the median wall-clock time is reported, so a single garbage-collection pause is not the published figure. The destructive Maximum mode, which converts pages to images, is not measured here: its result is a picture of the document, and comparing that on file size alone would be misleading.

The corpus

Six documents, chosen to span the cases that behave differently rather than to produce a flattering average. The checksum is the first 16 hex characters of the file's SHA-256, so a rebuild can be confirmed as identical.

Results

"Images" is how many embedded images were recompressed out of how many the document contains. "Text" is the number of words extracted from the output with pdftotext, compared against the same extraction from the input.

Quality and integrity checks

Two checks were run on every output. The first renders page one of the input and the output at the same resolution and reports the mean absolute per-channel difference, on a 0–255 scale — a number near zero means the page looks the same, and a large number would mean something went wrong such as an inverted or blank image. The second runs qpdf --check to confirm the file is structurally valid rather than merely openable.

Observations

The photographs are the file. The text-only agreement is 42 pages and under 100 KB; the 18-page scan is 10.5 MB. Page count is almost irrelevant to PDF file size. What matters is whether the pages are instructions or pictures.

Over-resolution is where the savings come from. The brochure lost 91.3% not because the images were badly compressed but because they were far larger than the space they were drawn in — a 1100-pixel-wide photograph placed in a 230-point frame is about 344 DPI, and reducing it to 150 DPI removes roughly four fifths of its pixels before any quality change. A document whose images were already sized for the page has much less to give.

Text survived every non-destructive run. All six documents that had a text layer extracted exactly the same word count afterwards, which is the expected result of replacing image streams while leaving page content streams untouched — but it is worth measuring rather than assuming.

Compressing twice gains nothing. Feeding a Smart-compressed file back through Smart produced no change at all: all 30 images were examined and none could be made smaller, so the original was kept. Running the same file at the Strong setting did reduce it further, because that is a genuinely lower resolution and quality target, not a second pass at the same one.

A scan is the hardest case. It has no text to protect and nothing but images to work on, so it responds well in percentage terms — but it starts far larger, so the result is still the biggest file in the set.

Reproducing this

The corpus generator, the measurement harness and the verification script ship with the site under tools/: benchmark-corpus.py builds the six documents from fixed seeds, benchmark-run.mjs drives the engine in a real browser, and benchmark-verify.py runs the text-extraction and rendering checks. The generated results in config/benchmarks.php are what this page reads — no figure on this page is written by hand, and changing the engine without re-running the harness leaves the old run's date visible rather than producing new claims.

Read more about this

• How PDF compression actually works
• Why some PDFs will not get any smaller