PDF Compression Benchmark

Methodology

File Maktab's compression engine walks every page of a PDF, finds the embedded JPEG images, and re-encodes them at the quality and maximum dimension of the chosen preset. Text, vector graphics, and document structure are not touched; the file is then re-saved with compressed object streams. Because the engine's only lever is the embedded images, the benchmark is designed around document types whose image content differs.

Each of the twelve samples was generated deterministically (seeded random content, fixed PDF metadata timestamps), then compressed once per preset. Every measurement ran twice; both runs produced byte-identical results, so each published number is a single exact measurement rather than an average. The benchmark clock is pinned during compression because the PDF writer stamps a modification date into the file metadata — a difference of a few bytes that has nothing to do with compression.

Size reduction is defined exactly as: reduction % = (original size − compressed size) ÷ original size × 100. Sizes below are shown in KB or MB for readability; the underlying measurements are exact bytes.

The three presets are the ones the production tool exposes:

Dataset

Twelve synthetic documents in six categories, two per category. Every file was purpose-built for this benchmark — no user files, no customer data, no third-party documents. Photo-like images are gradient-and-grain JPEG fields; scanned pages are synthetic images with text-line strips and scanner-like noise; text and table documents contain only text and vector lines.

Results

Compressed size and size reduction for every sample at every preset. Images re-encoded equals the number of embedded JPEGs the engine rewrote; for text and table documents the engine correctly found nothing to compress.

What the results mean

Within this benchmark dataset:

• Image content decides almost everything. The two text-only categories — dense reports and spreadsheet tables — measured 0% reduction at every preset, because the engine found zero embedded images to re-encode.
• Image-heavy documents compress the most: an average of 91.2% at the recommended preset and 97.1% at strong compression. Most of that gain comes from downscaling large embedded photos to the preset's maximum dimension, not from quality loss alone.
• Scanned documents behave like image documents, because a scan is an image. They averaged 75.7% at the recommended preset — but notice the high-quality preset only reached 9.4%: our synthetic scans (1240 px wide) already sit under that preset's 2200 px dimension cap, so only the lighter re-encode applied.
• Mixed documents land in between, tracking how much of the file is images: 85.1% to 93.2% at the recommended preset depending on image size.
• The preset choice is a genuine trade-off, not a formality: on the 12-image photo document the measured spread between strong and high quality is 533 KB versus 10.87 MB from the same 18.62 MB original.

Compression for email

The most common reason to compress a PDF is an email attachment limit. Gmail and Outlook.com both publish a 25 MB per-message attachment limit, and many corporate gateways are stricter — check the limit of the service you actually send through.

Read against the measured table: our 18.62 MB photo document fits under 25 MB before compression, but at the recommended preset it becomes 1.63 MB — trivially attachable, with room to spare for the rest of the message. The 3.93 MB scanned document becomes 0.96 MB. The text reports were never a problem at all: at 43 KB and 107 KB they were already far below any limit, which is exactly why compression returned 0%.

The benchmark also shows when compression is the wrong tool: a document that is already small gains nothing, and a document that stays too large after compression needs a different answer — splitting it, or sending a download link instead of an attachment. For the full workflow, read how to compress a PDF for email.

Limitations

• The dataset is synthetic. Photo-like images are gradient-and-grain fields, not real photographs; real camera photos contain different detail patterns and will measure somewhat differently.
• Twelve samples in six categories illustrate how document structure drives compression; they are not a statistical model of all PDFs.
• Real-world text PDFs usually embed fonts and are larger than our font-free text samples, but they still contain no compressible images, so the 0% finding generalizes even if the byte counts do not.
• Measurements come from one engine — File Maktab's browser compression engine in Chrome/151.0.7922.173. JPEG encoding is implemented by the browser, so other browsers and versions may produce slightly different bytes. No competitor tools were measured.
• Visual quality was not scored. What the engine does to images is stated exactly — JPEG quality 0.42/0.55/0.78 and maximum dimensions of 900/1400/2200 px — so the quality trade-off is defined by those parameters rather than by a subjective rating.
• PDF metadata timestamps were pinned during measurement for reproducibility; metadata accounts for a few bytes either way.

Reproduce this benchmark

Everything on this page is reproducible. The dataset generator and measurement harness live in the File Maktab repository at benchmark/browser-entry.ts and benchmark/run.mjs. Running node benchmark/run.mjs regenerates the twelve samples deterministically, runs the production compression engine (client/src/lib/pdfCompressionEngine.ts) against every sample and preset twice inside headless Chromium, verifies the two runs are byte-identical, and writes the measured dataset to shared/pdfCompressionBenchmark.ts — the same data file this page renders. No user files are involved at any step.