Compress a Scanned PDF on Mac (Without Killing OCR)

Because it is not a document. It is a photograph of a document, and photographs are expensive.

To make that concrete we built the same three-page agreement twice. Once as a normal PDF with embedded fonts, straight out of a browser print engine. Once as a 300 PPI color scan of those exact pages, with the blur, skew and sensor noise a flatbed adds.

Fifty-seven times larger, for the same words. Every letter that was a reference to a glyph in a font is now several hundred colored pixels, and your scanner saved the paper texture at the same fidelity as the type.

That is why a scanned contract blows past an upload limit that a word-processor export would clear with room to spare, and why the only lever that moves the number is resolution. There is no font to subset, no duplicate object to merge, no structure to repack. You are compressing photographs. The full comparison of every Mac compression route covers the other document types.

Further than instinct suggests, and then it falls off a cliff. We ran the scan through all five Smol presets, which are long-edge pixel caps rather than DPI targets, then fed every output back to Tesseract and scored the extracted words against the original 1,405.

Read the last two rows again. At 82 PPI an OCR engine still recovers 96.8% of the words. At 55 PPI it recovers 1.42%, which is noise. The page did not get gradually worse. It crossed a line where the stroke width of 10.5 pt type falls under about one pixel, and below that line the letterforms stop existing.

The 99.93% on Original against 100% on the two presets below it is a single word out of 1,405. That is recognition noise, not a trend, and we are reporting it rather than rounding it away.

Our sibling article on reducing PDF file size without wrecking the text measured the same collapse on a different document and puts the DPI decision in context. The practical rule out of both runs is the same: stay at or above 150 PPI for anything with body copy, and treat 100 PPI as the floor for anything you might need to read again.

Add the text layer before you compress, not after. This is the whole trick, and it inverts what most people do.

An OCR pass writes a second, invisible copy of the page into the PDF: the same words, positioned over the picture of the words, drawn in a font with no visible glyphs. That layer is what ⌘F searches and what Spotlight indexes. It is text, not pixels, so image compression cannot touch it.

We proved that by OCRing the scan first and then running all five presets over the result:

Every preset, all 1,405 words. Even tiny, where the picture of the page is illegible to a human and worth 1.42% to an OCR engine, is still perfectly searchable, because the search is not reading the picture.

The text layer costs almost nothing. At the tiny preset the searchable file is 65,126 bytes against 47,373 without the layer: 17,753 bytes for three pages, under 6 KB a page. There is no size argument for skipping OCR.

OCRmyPDF is the tool. It wraps Tesseract, keeps the original page images, and writes the invisible layer underneath. Install it once:

brew install ocrmypdf

Then run it. Both of these were run on the 5,017,560-byte test scan:

# add a text layer, leave the images alone
ocrmypdf scan.pdf searchable.pdf

# add a text layer and re-encode the images on the way through
ocrmypdf --optimize 3 --jpeg-quality 70 scan.pdf searchable.pdf

Note the second row. OCRmyPDF on its defaults made the file 45.1% smaller while adding a text layer, because it re-encodes the scanner’s wasteful JPEGs on the way through and keeps all 300 PPI. If you need the scan at full resolution for a print or a filing, that single command is the entire job.

If you would rather not touch a terminal, the same order of operations applies to any GUI route: OCR in whatever tool you have, then compress the OCR’d file. The compressor does not care which tool wrote the layer.

One of the four we tested, and it is the one macOS hands you for free.

Preview’s Reduce File Size applies a Quartz filter, and a Quartz filter does not compress a PDF so much as rebuild it through Quartz’s own PDF writer. On the way through, the invisible OCR font is re-subset and renamed, and the character map that made it readable does not come out the other side.

Zero. A document that contained the word Confidential eight times contains it zero times after the pass, according to poppler, MuPDF, and Apple’s own PDFKit. What is left is not damaged text, it is not text: across the 188 tokens pdftotext still reports, a search for any run of two or more letters returns nothing at all.

The mechanism is visible in one command. Before the filter, the fonts list shows Tesseract’s layer. After it, the same object is a renamed subset with no usable mapping:

pdffonts searchable.pdf
# GlyphLessFont   CID TrueType   Identity-H   yes no yes

pdffonts after-preview.pdf
# AAAAAB+font0000000030685d5b   CID TrueType   Identity-H   yes yes yes

Nothing on screen changes, which is what makes it dangerous. The pages look right, the file is smaller, and the searchability you paid for in OCR time is gone. We took Preview’s filter apart in detail in why Preview’s Reduce File Size ruins PDFs; this is one more entry on the list.

The practical check takes five seconds: open the compressed file, press ⌘F, and search a word you can see on the page. If it finds nothing, the layer is gone and you need to OCR again from the original.

For a black-ink document on white paper, yes, and it is the most under-used lever in this whole category. Grayscale throws away two of the three color channels and keeps every pixel of resolution.

Two-thirds off with the resolution untouched. For a scanned passport page, a court exhibit, or anything where a reviewer needs to read small print, that is a far better trade than dropping to 150 PPI in color. The command:

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.6 \
   -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=gray.pdf scan.pdf

Once you are at 150 PPI the color channels barely matter any more, which is why the last two rows are within 6% of each other. Grayscale is a full-resolution move, not a stack-it-on-top move. The rest of the terminal toolkit is in compressing PDFs from the Terminal on macOS.

• Check whether a text layer already exists. Open the file, press ⌘F, search a visible word. If it hits, skip to step 3.
• OCR the original at full resolution. ocrmypdf scan.pdf searchable.pdf. Never OCR a file you already compressed. Ours scored 1.42% at 55 PPI.
• Convert to grayscale if the ink is black. Two-thirds off with no resolution loss.
• Compress to the resolution the destination needs, not the smallest one available. 150 PPI and above for body copy.
• Search the output before you send it. One ⌘F catches a destroyed text layer in five seconds.

If the scans arrive by the folder rather than one at a time, the OCR step is the slow part and it parallelizes badly, so run it as a loop overnight and keep compression as a separate, fast pass. Batch compressing PDFs on Mac covers that side. If the problem is an upload form rejecting the result, our guide to PDFs that are too big to upload has the target-size table.

Three cases from this test where something else is the better tool, and we would rather say so up front.

Your scan has no text layer and you need one. We compress PDFs. We do not run OCR, and no compression setting will ever add a searchable layer. OCRmyPDF is free, it is one brew install, and on its defaults it made our test file 45% smaller as a side effect. Run it first. We are the second step, not the first.

You need to keep exactly 300 PPI. Our presets are pixel caps, so on a US Letter page the ceiling is 2,400 px on the long edge, which is 218 PPI. If a filing rule or an archive standard specifies 300, use Ghostscript with an explicit resolution target, or grayscale conversion on its own, and leave the pixel count alone. Same story for anything heading to a press, which we go through in compressing a PDF for print.

It is one file, once, and nobody will search it. A single scanned receipt going into an expense form does not need a $29 app. Preview’s Reduce File Size will get it under the limit, and the text layer it destroys is one you were never going to use.

Where we do earn it: a folder of scans, a text layer that has to survive, and wanting a resolution ladder rather than one button. Smol is $29 once, it runs entirely on your machine, and nothing about a scanned contract should be uploaded to a stranger’s server anyway. If you want the wider field, we compared the Mac PDF compressors including where each one wins.

Everything here was run on 26 September 2026 on a MacBook Pro (Mac14,9) with an Apple M2 Pro, 10 cores and 16 GB of RAM, on macOS 27.0 (build 26A428). Sizes are raw bytes from stat. Image dimensions and effective resolution come from pdfimages -list.

Fixture provenance. The test document is a 1,405-word services agreement we wrote ourselves for this article. It was rendered to PDF with headless Chrome (Skia/PDF m153), rasterized to three 2,550 × 3,300 pages with pdftoppm -r 300, then given the artifacts a flatbed adds with ImageMagick 7.1.2: a fraction of a degree of skew, a 0.6 px blur, Gaussian sensor noise and a slight paper tint. The pages were reassembled into a Letter-size PDF at 300 PPI. No customer document, no personal file and no third-party copyrighted material was used.

OCR scoring. Each output was rendered back to grayscale PNGs at 300 DPI with pdftoppm and read by Tesseract 5.5.2 in --psm 6. Accuracy is the proportion of the 1,405 ground-truth words recovered by sequence alignment, so both substitutions and dropped words count against it.

Tool versions. Ghostscript 10.07.0, qpdf 12.3.2, poppler 26.04.0, OCRmyPDF 17.4.2, MuPDF 1.27.1, Smol 1.0.35. Preview’s filter was applied by handing /System/Library/Filters/Reduce File Size.qfilter to PDFKit’s write(to:withOptions:) with the QuartzFilter option, which is the same code path the app’s export sheet uses.