PDF Compression Benchmark

Last updated: August 27, 2026

PDFmuto's compression benchmark processed 8 public-domain documents totaling 6,059 pages through the in-browser Compress tool. Median file size fell 2.7%, five of eight files shrank, and the best result — an editor-saved 20.9 MB government PDF — compressed 31.1%. All processing ran locally; nothing was uploaded.

Key results at a glance

Methodology

We selected 8 public-domain and US-government documents that represent the way real PDFs behave: tax forms, legislative reference books, instructions with graphics, and a government gazette. The corpus spans 2 to 2,862 pages per file, from 137 KB to 20.9 MB.

Each file was processed with the exact settings the PDFmuto Compress tool applies in your browser:

The measurement is a single deterministic pass per file — no averaging over runs, no cherry-picking. Every source file is linked in the table below so anyone can reproduce the test.

Results

DocumentPagesBeforeAfterChange
IRS Form W-4 (2024)5204 KB208 KB+2.2%
IRS Form 1040 (2023)2215 KB217 KB+0.8%
IRS Form W-9 (2024)6138 KB131 KB−4.5%
Instructions for Form 10401264.2 MB4.5 MB+7.0%
Declaration of Independence & Constitution853.8 MB3.8 MB−0.9%
Constitution Annotated (2022)278013.4 MB12.6 MB−5.7%
Constitution Annotated (2016)286220.0 MB13.8 MB−31.1%
Federal Register, Jan 7 20221937.0 MB5.7 MB−18.5%
Total605948.9 MB40.9 MB−16.4%

Why some PDFs grow (and what that means for you)

The three files that grew — two IRS forms and the Form 1040 instructions — were already tightly packaged by the government's production pipeline. Repacking had nothing to remove, and the rewrite added a small amount of overhead. This is the honest trade-off of repack compression: it shines on documents saved by desktop editors, which tend to accumulate redundant data, and does little on professionally packaged files.

The best result, −31.1%, came from a 20.9 MB document saved by an older production tool. That pattern — large files, editor-generated, heavy metadata — is exactly where this type of compression wins. If your PDF was scanned or is dominated by images, repacking will not shrink it much; image re-encoding is the lever there.

Try it on your own file

The exact process measured here is the free PDF Compress tool. It runs in your browser with no upload — drop a PDF in, and the same pdf-lib pipeline produces your result on your device. For image-heavy documents, expect modest gains from repacking; for editor-saved documents, expect the kind of reduction the table above shows.

Curious how a website can process PDFs without a server? See ourlocal processing architecture explainer.

FAQ

How much can PDF compression actually shrink a file?

In this benchmark the median reduction was 2.7% and the mean 6.3% across 8 public-domain documents. Results range from 31.1% smaller (a bloated editor-saved document) to 7% larger (a file already tightly packaged). The outcome depends on how the PDF was created, not on the file's page count.

Why do some PDFs grow during compression?

Repack-style compression rewrites a PDF's internal structure but does not re-encode images. A file that is already tightly packaged — like the IRS forms in this benchmark — has little to gain, and the rewrite can add a small amount of overhead, up to 7% in the worst case here.

What is the difference between repacking and re-encoding a PDF?

Repacking removes redundant data and restructures a PDF without touching its images or text. Re-encoding recompresses images at a lower quality, which is where most size is won in image-heavy documents. The two methods are complementary; repacking alone cannot compress a scanned document much.

How was the benchmark run?

Eight public-domain US-government PDFs were processed with the same pdf-lib settings the live Compress tool uses on your device: metadata updates disabled, producer and creator strings cleared, and object streams enabled. Every source file is linked from the results table, so the test is fully reproducible.