Part of my freelance work is handing over a product manual as a PDF. The layout person drops full-size photos and screenshots in, the file lands somewhere around 20 MB, and a week later the client writes back: "Can you make it smaller? I can't send it." It's unpaid work, so I've always just picked the smallest option in whatever tool was open and moved on.
I finally sat down and tested that habit on a manual built the way my deliverables usually are. It turns out "smallest" was the wrong default, and the preset literally labelled for email is the one that breaks the manual.
The test file
To be clear, this is not a client's document. I built a fake 8-page A4 manual for a made-up brand, LEAF CO (the text inside is Chinese). Every page has one photo, one admin-dashboard screenshot with sample data, a few paragraphs and a vector bar chart. The photo started as a CC0 image from Wikimedia Commons, which I cropped, recolored and upscaled to 4032×3024. The screenshots are 2880×1800 PNGs.
Total: 19,458,294 bytes. Images are 99.23% of that. Fonts, text and the charts together are under 1%, so compressing this PDF really means compressing its images.
The number that explains the size is effective DPI: pixels divided by the inches the image occupies on the page. The photo is 4032 px wide but only 9 cm on the page, which works out to 1138 dpi. The screenshots come out at 430 dpi. Nobody needs 1138 dpi on a screen.
Four presets, four outcomes
I ran it through the PDF compressor at imging.ai, mostly because it runs in the browser and I don't like uploading client material anywhere. You can check that yourself: with DevTools open on the Network tab, I saw no non-GET requests during the whole run, only blob: URLs. Its presets are really DPI ceilings for embedded images.
Screen / email, 72 dpi: 352,318 bytes (the UI shows 344 KB, 1.8% of the original). The screenshots get squeezed to 482×301 and a 256-color palette. The small text in the tables is gone. Not "a bit soft", unreadable.
E-book, 150 dpi (the default): 864,614 bytes (844 KB, 4.4%). Screenshots end up at 1005×628 and the table text is clear. All 8 pages are there, and the 3,357 characters of text compare identical and stay searchable. Rendering every page at 150 dpi and comparing with the original gives an average PSNR of 41.3 dB.
Print, 300 dpi: 3,722,437 bytes (3.55 MB), PSNR 54.7 dB. The photos drop to 1063×797. The screenshots are left alone, because 430 dpi is under the print threshold.
Lossless structure: doesn't touch pixels, saved only a few KB on this file.
What about the macOS built-in option?
My previous go-to was the "Reduce File Size" Quartz filter you can pick when exporting from Preview. For this test I called the same system filter file directly rather than clicking through Preview's export dialog, so I haven't confirmed the GUI gives byte-identical output.
It produced 1,432,231 bytes: 66% larger than the E-book preset, with a lower PSNR of 38.0 dB. It resamples everything to 144 dpi and re-encodes everything as JPEG, screenshots included. And simply re-saving the file with PDFKit made it 3% bigger, which I did not expect.
The rule I use now
- Client will read it on screen, forward it, or put it on a shared drive: E-book (150 dpi).
- Client will print it: Print (300 dpi). At 72 dpi each photo is 255 px wide sitting in 9 cm of paper. I didn't actually print it, but the arithmetic is enough.
- Screen / email only for photo-only booklets with no small text.
One more thing that bit me: the UI counts 1 MB as 1024 KB, so the original shows as 18.56 MB, while Finder reports about 19.5 MB. If someone gives you a size limit, check it both ways.
And whatever you pick, open the result and zoom into the page with the densest table before you hit send. That quick check is what caught the 344 KB version for me.
Top comments (0)