Upload forms love the line "PDF, max 2 MB". I wanted to know which of the no-install, no-account options actually gets a file under that line, so I built a few test PDFs and ran them through three methods on a Mac. The short version: whether the PDF is a scan mattered more than which tool I picked.
The test files
All of them are self-made with fictional content. An 8-page brochure for a made-up brand (19,458,294 bytes), with photos adapted from a CC0 image on Wikimedia Commons and screenshots of a fake dashboard. A 4-page "scan": a fictional form rendered as full-page 300 DPI images with noise and a slight tilt, 8,948,995 bytes, no text layer. (A text layer is the part of a PDF stored as real text, the part you can select and search. Scans don't have one; each page is just a picture.) And a 10-page text-only document.
DPI here means pixels per inch of the page. A 4032-pixel photo squeezed into a 9 cm box works out to 1138 DPI, far more detail than anyone will see on screen, and that is where most of the file size hides.
Method 1: just re-save it
Writing the brochure back out through macOS's PDF framework without any filter produced 20,040,400 bytes. That's 3% bigger. Re-saving is not compressing.
Method 2: macOS "Reduce File Size"
This is the Quartz filter you can pick when exporting from Preview. I applied the same system filter file directly rather than clicking through Preview's UI, so treat it as the same filter, not a byte-for-byte check of Preview's export. Its settings: JPEG quality 0.7, resample to 144 DPI, max 2400 px per side.
On the brochure it did well: 1,432,231 bytes, about 1.37 MB, text intact. The screenshots were converted to JPEG along the way, and PSNR came out at 38.0. PSNR is a score from comparing the compressed pages to the original pixel by pixel; higher means closer to the original.
On the scan: 2,905,274 bytes, about 2.77 MB. Still over.
Method 3: ImgIng, locally in the browser
ImgIng compresses PDFs inside the browser. I ran it on the Chinese-language version of the site with DevTools open; no request sent the file anywhere. It has four levels: Screen (72 DPI), eBook (150 DPI, the default), Print (300 DPI) and Lossless structure.
eBook on the brochure: 864,614 bytes (shown as 844 KB), 8 pages, text identical, PSNR 41.3. eBook on the scan: 1,927,707 bytes (shown as 1.84 MB). Under the line.
Detail from the self-made 4-page scan (fictional form; the sample text is Chinese). Top right: ImgIng Screen, 347 KB, soft edges. Bottom left: ImgIng eBook, 1.84 MB. Bottom right in red: macOS Reduce File Size, 2.77 MB, still over 2 MB.
Why scans behave differently
With the macOS filter the brochure shrank to 7.4% of its size and the scan only to 32.5%. ImgIng eBook: 4.4% versus 21.5%. The brochure's photos were wildly oversampled, so dropping to ~150 DPI throws away a lot. The scan started at 300 DPI and every page is one big image, so halving the resolution has less to give. Both tools land near the same resolution on the scan yet end up almost 1 MB apart; from the outside I can't tell why, my guess is different JPEG settings.
Text-only PDFs barely move. My 10-page sample was 85% embedded fonts; ImgIng saved 4.8% at every level and the macOS filter made it 3.4% bigger. That's one sample, so I wouldn't generalize, but if a mostly-text PDF is over the limit, compression probably isn't the fix.
Two things I check before uploading
Don't grab the smallest level by reflex. Screen got the brochure down to 352,318 bytes, but the small table text in the screenshots became unreadable. I start with eBook.
And check the unit. ImgIng shows sizes in 1024-based MB, while Finder uses 1000. The brochure reads 18.56 MB in one and about 19.5 MB in the other. I don't know which one a given upload form uses, so I check both: 1,927,707 bytes is under 2 MB either way; 2,905,274 bytes is over either way.
What I didn't test: "print to PDF", online upload-based compressors, and whether any specific site accepts the result. I only measured file sizes.
Top comments (0)