Tiny, Small, Medium, Large: What PDF Compression Presets Actually Do

A PDF is a container of objects. Four kinds of them account for essentially all of the file size, and a compression preset only meaningfully touches one.

Image XObjects are embedded raster images: photographs, scans, screenshots, chart exports. In a bloated PDF these are almost the entire file. Our brochure is 3,734,814 bytes, and its four JPEG streams measure 1055, 938, 836 and 814 KB: 3,643 KB of a 3,647 KB file. Everything else in the document rounds to nothing.

Content streams hold the drawing instructions, and embedded fonts hold the glyph outlines those instructions reference. Both are already Flate-compressed by almost every producer, and a subset font runs to tens of kilobytes. On a text-heavy document these two are the whole file, and the whole file is small.

Structure is the cross-reference table, the object headers, the document information dictionary, any XMP metadata packet, and optional page thumbnails. Rewriting it efficiently is worth a small but real amount, and we can put a number on it: our text-and-vector-only control file went from 7,095 to 7,077 bytes, a 0.3% saving, identically at all five presets. If a PDF has no images, a preset has nothing to work with. The size is the content.

This is the part almost every explainer gets wrong. A PDF does not store a DPI value for an image. It stores a pixel grid and, separately, a transformation matrix that says how large to draw that grid on the page. The resolution is a consequence of the two, not a property of either:

effective PPI = image pixel width ÷ placed width in inches

In our brochure a 2,250 px-wide photo is placed 7.5 inches wide, so it renders at 300 PPI. Place the same bytes 3.75 inches wide and it is 600 PPI; stretch them across a 15-inch poster and it is 150 PPI. That leaves a compressor two ways to implement a quality target, and the choice determines how its presets behave:

Resolution-targeted. Read the placement matrix, work out the current effective PPI, and resample only enough to hit the target. Ghostscript works this way. In our test, -dPDFSETTINGS=/screen produced exactly 72 PPI on both the brochure and the scan despite their very different page geometry, and /ebook produced exactly 150 PPI on both. Preview’s built-in Quartz filter works this way too: its ImageResolution is 144, with a separate ImageSizeMax of 2,400 px as a hard ceiling, and our output measured 144 PPI on both documents.

Pixel-capped. Ignore placement entirely and cap the longest pixel edge of every image at a fixed number. Smol works this way. It is cheaper, it is more predictable in bytes, and it drifts in DPI as page size changes.

Here is that drift, measured. The same Smol preset, two documents, two different results, because the images are placed at different physical sizes:

So when a tool advertises “150 DPI”, ask which of the two it means. Ours is a pixel cap, and we would rather tell you that than print a DPI number that is only true for one page size.

Each preset sets a longest-edge pixel ceiling and a JPEG quality value, and that is the whole configuration. Measured results on the two image-bearing test files:

Two things fall out of that table. The jump from Large to Original is where most of the remaining bytes live, because JPEG cost climbs steeply above quality 75. And the scan compresses harder than the brochure at every setting, because a page of black type on near-white paper has far less entropy than a photograph.

Not every image gets touched. Images below roughly 10,000 total pixels are skipped, as are JPEG streams already smaller than 8 KB. That is deliberate: logos, icons, signature stamps and rule graphics are left exactly as they were, because recompressing them costs quality and saves nothing. A recompressed image is also only kept if it is smaller than the stream it replaces, so an already-optimised PDF does not get worse.

Images inside a PDF are stored under a filter that says how the bytes are packed. The three you meet in practice are DCTDecode (JPEG), FlateDecode (zlib, the PNG-style lossless path) and JPXDecode (JPEG 2000, common in scanner output and archival formats).

Smol decodes what it can and writes every recompressed image back as baseline JPEG, whatever it started as. That has a consequence worth knowing before you hit the button. We built a single-page PDF holding one 1,400 × 933 px image stored as raw RGB under FlateDecode: 2,374,733 bytes. At the Large preset it came out at 103,404 bytes, a 95.6% reduction, with the pixel dimensions completely unchanged, because 1,400 is under the 1,800 px cap. All of that saving was the lossless-to-lossy switch.

For photographs that is a straight win. For a screenshot, a line drawing or a chart with crisp type it is where PDF compression visibly hurts: JPEG puts ringing around hard black-on-white edges, and that is the artefact people mean when they say a compressed PDF “looks fuzzy”. If a document is mostly UI screenshots, use Original or leave it alone.

JPEG 2000 streams are skipped rather than converted. If your scanner produced a JPX-encoded PDF, the images will pass through untouched and you will see a much smaller saving than the table above suggests. That is a real limitation and not a rounding error.

Colour conversion. CMYK images get special handling: they are routed through sips with the system sRGB profile, so a CMYK image comes out as sRGB JPEG. This is correct for screen-bound documents and wrong for print-bound ones. If a PDF is going to a commercial printer with a CMYK workflow, compressing it will convert your separations, and no preset avoids that. Send the press-ready file.

No, and it is the most reassuring fact about PDF compression. Text in a normal PDF is not pixels: it is a sequence of glyph references into an embedded font program, and glyph outlines are vector curves. A preset that resamples images has no mechanism to make text worse at any setting. We verified rather than assumed it. Extracting text from the Tiny output of our brochure with mutool draw -F txt returns the same body copy as the source, with the page count unchanged.

Font subsetting is the related trick people expect a compressor to do. An embedded font can carry a full character set running to hundreds of kilobytes; subsetting keeps only the glyphs the document uses. InDesign, Word and LaTeX all subset on export, so there is usually little left to win. Ghostscript’s pdfwrite device re-subsets fonts when it rebuilds a document. Smol does not, and leaves font programs exactly as it found them. If a PDF really is carrying unsubsetted fonts, Ghostscript is the tool that reclaims that space.

The exception that matters: in a scanned PDF there is no text, only pixels that look like text, and a preset absolutely will degrade them. Our simulated 300 DPI scan drops to 55 PPI at Tiny. For scans, start at Medium and only go lower after looking at the result at 100%.

Because “Original” means minimal loss, not no loss, and the name oversells it slightly. Three things happen even at the top setting.

Images above 2,400 px are still resampled. Our brochure photos are 2,250 px on the long edge, under the cap, so their pixel grid was untouched. Our scan pages are 3,300 px tall, over the cap, so they were resampled to 1,855 × 2,400 and dropped from 300 PPI to 218 PPI. Same preset, two different outcomes, for the reason explained above.

Images are still re-encoded at JPEG quality 88. That is high, but it is a re-encode, and a re-encode is generation loss. This alone took our untouched-resolution brochure from 3,734,814 to 1,818,893 bytes, a 51.3% saving with every pixel grid intact.

The document structure is rebuilt. The output is finalised with qpdf --linearize --object-streams=generate --compress-streams=y, packing the object table into compressed object streams and reordering the file for fast web viewing. That part is genuinely lossless, and it is what produced the 0.3% saving on our image-free control file.

If you need byte-identical image data, do not run a preset at all. Run a structural pass: qpdf --linearize in.pdf out.pdf reorders and repacks the document, loses nothing, and costs nothing.

We checked, and the answer for Smol is no. Running exiftool against the Tiny output of our brochure returns the same Producer, Creator, Title and CreateDate fields as the source file. Compression presets recompress pixels; they do not sanitise documents.

That matters because PDF metadata is more revealing than people assume. The document information dictionary and the XMP packet can carry the author’s name, the software and version used, creation and modification timestamps, and in some producers the local file path of the source document. None of it is visible on the page and all of it travels with the file. Page thumbnails are a separate case: a thumbnail stored as an image XObject is an image like any other, so it gets recompressed rather than removed.

Smaller file, use a preset. Clean file, use a metadata strip. Smol keeps those as two separate actions precisely because conflating them leads people to believe they have removed something they have not.

The heuristic that works: read once on a screen, Small. Might zoom, Medium. Might get printed, Large. Everything else is one of the special cases above.

When a spec names a DPI. Journals, print vendors and some government portals specify “images at no more than 300 dpi”. A pixel cap does not enforce that, because the resulting DPI depends on page size. Use Ghostscript, where -dPDFSETTINGS=/ebook produced exactly 150 PPI on both of our very different test documents, or Acrobat’s PDF Optimizer, where you type the ppi value yourself.

When different images need different settings. One preset applies one ceiling and one quality to every image in the document. A scanned signature page and a product photograph want different treatment, and Acrobat Pro’s Images panel is the only tool here that separates colour, greyscale and monochrome handling.

When the PDF has no images. We measured 0.3% on a pure text-and-vector file. If your 400 KB report is all type and charts, nothing will change that number, and anyone promising otherwise is selling something.

When the file is going to a commercial printer. Compression is for files you send to people, not to presses.

And the obvious one: if you compress a PDF twice a year, macOS Preview applies a 144 PPI JPEG filter for free. The full field is compared in the best PDF compressor for Mac, and the step-by-step methods are in how to compress a PDF on Mac. If it is images rather than documents you are wrestling with, every image compression method on Mac covers the same ground. When you want the local, unlimited version of all of this, Smol is $29 once.