Text PDFs shrink by losing the photo, scanned PDFs by losing DPI

A small product tends to come with two kinds of PDF: a manual with a few photos, and a form a client signs, scans and sends back. To see whether one compression rule fits both, two self-made 2-page test files were each run once through four free tools on an Apple M4 Mac on 2026-11-06. The files started at almost the same size, 2.31 MB and 2.36 MB (1 MB = 1,000,000 bytes here), and they turned out to be two different problems.

Both files are self-made, so here is what they are. The text one is A4 with Chinese and English text from 12 pt down to 6 pt, fonts embedded, plus one photo derived from a CC0 image on Wikimedia Commons. The scanned one is the same two pages rendered as 300 dpi images with noise, blur and a slight tilt, an imitation rather than a real scan. "Readable" below means the character accuracy that macOS's built-in text recognition gets on the 6 pt and 8 pt blocks.

In a text PDF one photo is the whole file

The text file is 2,312,093 bytes, and almost all of it is a single 4032×3024 JPEG placed 12 cm wide on page 1. Effective resolution is pixels divided by the size on the page in inches, and 4032 pixels across 4.72 inches comes out at 853 dpi, far above any of the 72, 150 or 300 dpi preset targets. The text is vector glyphs plus a font subset. All four tools resampled that photo. The macOS Reduce File Size Quartz filter, the one Preview's export offers, gave 190,237 bytes (−91.8%) with the photo at 144 dpi. Ghostscript 10.07.1 with /ebook gave 107,991 bytes (−95.3%), iLovePDF's recommended level 129,831 (−94.4%). The fourth was ImgIng https://imging.ai/ in a desktop browser on the Ebook preset, which gave 160,010 bytes (−93.1%) with the photo at 709×532, 150 dpi. In the macOS, iLovePDF and ImgIng outputs the text areas render exactly like the original, 6 pt lines included, because nothing touched them.

Without a photo there is little to win: on 2026-09-17 a 10-page text-only PDF of 137,782 bytes, 85% of it fonts, shrank only 4.8% on every preset of the same browser tool.

A scanned PDF has nothing to keep except pixels

The scan file is two full-page JPEGs, each 2481×3508 at 300 dpi, with no text layer. The small print is pixels too, so every byte saved is detail thrown away, and the tools spread out much more.

Around 150 dpi the fine print survives everywhere, so the choice is mostly about bytes. The macOS filter has the lowest target of the group at 144 dpi, yet its output is the largest, because it kept the page JPEGs much heavier. The browser tool's file is more than twice the size of iLovePDF's and Ghostscript's at the same 150 dpi. Its PSNR on the 8 pt area came out a bit higher, 26.47 against about 23.6, which I read as a hint and nothing more.

Then comes the cliff. Going to 72 dpi gave 125,569 bytes on the browser tool's Screen preset and 109,894 on Ghostscript /screen, but 6 pt accuracy fell to 41.5% and 7.6%, and 8 pt to 88.9% and 70.2%. A 6 pt letter at 72 dpi is about 6 pixels tall (6 × 72 ÷ 72), which in this test was not enough to tell characters apart. A separate one-page test with Chinese and English lines showed Chinese slipping a step earlier: at 100 dpi Chinese 6 pt read at 81.3% while English 6 pt was still 99.1%. My guess, and it is only a guess, is that dense strokes start merging into blobs around 8 pixels.

The high end does nothing for a scan either. The 300 dpi Print preset left it at 2,355,587 bytes, and Ghostscript /printer made it 0.08% larger. Ghostscript leaves an image alone until it is about 1.5 times the target, and a 300 dpi scan is nowhere near 450 dpi.

What to check before picking a preset

Start with pdfimages -list on the file and look at the x-ppi column. If the big images are photos sitting well above 150 dpi inside an otherwise text document, any 150 dpi setting takes out 90% or more and the text stays sharp, so the tool can be chosen on other grounds. One of them is whether the file leaves your machine: iLovePDF uploaded the whole file in this run, while ImgIng's site says PDF compression happens locally, and its six runs here showed no non-GET requests. If the pages are full-page images at 300 dpi, the target DPI is the only setting that matters. Here 150 kept the fine print readable, 72 did not, and the print presets saved nothing, so for a scanned contract I would stay at 150 and pay for the extra kilobytes.

Real scanner output, phone-camera scans with uneven light and CMYK print files were not in this test. In a 2026-10-16 run ImgIng compressed a CMYK print report by only 2.6% because its CMYK images were kept as they were, so print files need their own check.