Reduce PDF File Size on Mac Without Wrecking the Text

Open the file in Preview and try to select a word. If a text highlight appears, the PDF contains real text: glyph drawing instructions plus an embedded font program. If the cursor only drags a rectangle, you are looking at a picture of a document.

Same test in one step: press ⌘F and search a word you can see. No result means no text layer. Anything off a flatbed scanner, a multifunction printer, an iPhone Notes scan, or a photographed contract lands here unless someone ran OCR on it.

The third row catches people out. An OCR’d contract still looks like a picture to a compressor, because it is one. The searchable text riding underneath keeps working however hard you compress, which is why a squashed OCR PDF can be fully searchable and completely unreadable.

A PDF page is a list of drawing operators. Text operators say “set font F1 at 11 points, move here, draw these glyph IDs.” The outlines live in an embedded font program, and the renderer rasterizes them fresh at whatever resolution your screen or printer asks for. None of that is stored as pixels, which is why you can zoom to 1600% in Preview and the letters stay sharp.

Images are the opposite: encoded pixel streams, usually DCTDecode (JPEG) or FlateDecode, at a fixed pixel count. The page says “paint this image into a rectangle 6 inches wide.” Effective resolution is pixels divided by printed inches. A 1,800 pixel wide photo placed 6 inches wide is 300 PPI. The same photo placed 12 inches wide is 150 PPI, with nothing in the file changing.

Every mainstream PDF compressor works on that second category: decode each image, resample it to fewer pixels, re-encode as JPEG, rewrite the stream. Text operators and font programs are copied across untouched. On our 16-page test document the extracted text was exactly 14,618 characters before compression and exactly 14,618 after, at all five quality levels.

So when compression ruins a PDF’s text, one of two things happened. Either the document was scanned, and the compressor downsampled the letters along with everything else. Or the tool rasterized the whole page on its way out. Different failures, different fixes.

For a scanned page, legibility is arithmetic. The pixel height of one em is point size × DPI ÷ 72. Body text is 10 to 12 points, so at 11 points:

Here is what that looks like in practice. We rendered a 16-page document to 300 DPI page images so it behaved exactly like a scan, ran it through five compression levels, then pulled page 3 back out and fed it to Tesseract 5.5.2. Ground truth: 220 words.

The cliff is not gradual. Accuracy holds at 100% down to 164 DPI, slips a fraction of a percent at 109, loses a word in twenty at 82, then collapses at 55. That is how raster type fails: slowly, slowly, and then all at once when stroke width drops below one pixel. If an OCR engine still reads a page at 95.5%, a human at normal zoom will manage. Below that, both of you are guessing.

Pick by destination, not by how small you want the number to be. The five PDF quality levels in Smol, with the effective resolution each produced on a photo placed 6 inches wide and the measured result on our 16-page test document (2.0 MB, text plus eight 300 PPI photos):

One thing explains results that otherwise look inconsistent. These levels are not fixed DPI targets. They are caps on the longest edge of each stored image: roughly 600, 900, 1,200, 1,800 and 2,400 pixels. The DPI you get is that cap divided by the inches the image occupies.

Where photos were placed 6 inches wide, Small produced 900 × 600 pixels, or 150 PPI. On the scanned twin, where the image covers a full 11 inch page, the same Small level produced 695 × 899 pixels, or 82 PPI. Same setting, resolution nearly halved, because the picture is stretched across almost twice the paper. So for full-page scans, move up one level from whatever you would pick for a normal document.

Because compressors only have images to work with, and most PDFs are mostly not images. Four files built for this article, each run through all five levels:

Look at the two left columns. The text-only PDF and the vector chart deck land on the same number at every quality level, because there is no raster data to resample. You get one fixed structural saving and the quality slider does nothing. Choosing Tiny on a text document is not aggressive. It is inert.

The byte composition explains it. In the text-only file, embedded font programs are 30.0% of the total and images 0%. In the text-plus-photos file, fonts are 1.4% and images 95.9%. In the scanned file, images are 99.8%. Whatever fraction of your PDF is images is the fraction a compressor can operate on.

It also tells you when to stop. If a 40 MB PDF barely moves, look for something other than photos: a huge vector map, thousands of CAD paths, or a full font family embedded without subsetting. Full breakdown in compress a PDF without losing quality on Mac.

You do not have to trust anyone’s description of it. The filter is a property list on your Mac. Run this in Terminal:

plutil -p "/System/Library/Filters/Reduce File Size.qfilter"

On macOS 27.0 that prints Compression Quality 0.7, ImageCompression ImageJPEGCompress, ImageResolution 144, and ImageSizeMax 2400. One quality value, one resolution target, no adaptation to the document. That is the entire configuration, and it matches the long-standing complaint on Apple Stack Exchange that Preview compresses too hard with only one setting.

Applied to our four test files through the same Quartz filter Preview uses:

Preview made the text-only PDF nearly four times bigger. That is the behavior behind every forum thread titled “why did Reduce File Size increase my PDF.” The filter rewrites the document through Quartz’s PDF context, and with no images to shrink, the rewritten content streams are simply larger than what the original producer wrote.

Credit where it is due on the other half of the table: at 144 DPI the scanned pages still scored 100% OCR accuracy, so Preview is not what turns scanned type to mush. Its real problem is one setting and no idea what your document is. Longer teardown in why Preview’s Reduce File Size ruins PDFs.

Pick a level that matches the destination, apply it, check the result. In Smol: drop the PDF on the window or the menu bar icon, choose Tiny, Small, Medium, Large, or Original, read the per-file saving. Every level leaves the text layer intact, which we verified by extracting the text from all five outputs and getting 14,618 characters each time.

Two habits. On a vector PDF, start at Small and go up only if a photo looks soft, because text cannot get worse. On a scan, start at Medium and treat Tiny as off limits.

Batches are where a local tool stops being a convenience. Twenty copies of the 2.0 MB test document at Small finished in 2.83 seconds on an M2 Pro: 38 MB of PDF processed before a browser upload would have finished negotiating. Step-by-step single-file version in our help article on reducing PDF file size, and the five-method comparison in how to compress a PDF on Mac.

The quiet advantage shows up when the PDF is a signed contract, a medical record, or an unreleased deck. Smol works on your own machine, so the file never leaves it. Web compressors are fine tools, and also a third party you just handed a document to. Smol is $29 once, with no per-file limit and no account.

You have one small PDF and no strong feelings about it. Preview is already installed, it is free, and on an image-heavy document it took 2.02 MB down to 827 KB in our test. If that clears your limit, you are done. Do not buy software.

You need OCR on a scan that has none. Smol compresses PDFs, it does not add a text layer. Run an OCR tool first, then compress the result. ocrmypdf via Homebrew does this well and keeps the original page images.

You need to edit content, redact, or reorder pages. That is an editor job. Acrobat, PDF Expert, and Preview’s page thumbnails all do things Smol does not.

Your PDF has no images in it. The text-only column above tells the story: 11.8% and no setting changes it. That is not a compression problem, and no app will make it one.

You are not on a Mac. Smol is macOS only. On Windows or Linux, Ghostscript with -dPDFSETTINGS=/ebook gets you to roughly the same place for free, with a worse afternoon.

Everything above was run on 2026-09-26 on an Apple M2 Pro, macOS 27.0 (build 26A428). Four test PDFs were built for the article rather than borrowed, so it is reproducible:

Text only is 10 US Letter pages of 11 pt Georgia body text, printed to PDF by headless Chrome 153 (producer Skia/PDF m153). Vector charts is 12 pages of inline SVG charts, same producer, no raster data. Text + photos is 16 pages of that body text with eight photographs placed 6 inches wide from 1,800 pixel sources, so each sits at exactly 300 PPI. Scanned pages is the same document rendered to 300 DPI JPEGs with pdftoppm and reassembled, which puts 99.8% of its bytes in images and leaves no text layer.

File sizes are byte counts from stat, shown in the decimal KB and MB Finder uses. Image dimensions and effective PPI come from poppler’s pdfimages -list, text layer survival from pdftotext character counts before and after, and byte composition by object type from pikepdf 10.3.0. OCR accuracy used Tesseract 5.5.2 at --psm 6, scoring recognized words against the source text. The macOS comparison applied /System/Library/Filters/Reduce File Size.qfilter through the same QuartzFilter API Preview uses.

Your own PDF will not match these numbers, and that is the point. Run pdfimages -list yourfile.pdf and read the x-ppi column. That number tells you how much room a compressor has, before you try anything.