How to compress a PDF without losing quality

“Without losing quality” has a precise meaning once you look inside the file. A PDF page is a list of drawing instructions. Some paint text with a font, some draw lines and shapes, and some paint a sampled image: a scan, a photo, a screenshot. Text and vector drawings are already compact and do not get meaningfully smaller. Almost all the weight in a large PDF is image data, and almost all “compression” means re-encoding those images at a lower resolution or a lower JPEG quality.

So the useful question is not “how do I compress without loss” but “how much image detail can this document give up before a reader notices, and does the text layer need to survive.”

What each level does

Compress PDF has three levels. They are not three strengths of one method.

• Low downsamples and re-encodes the embedded images, gently. Text, fonts, vector drawings, and links are left alone. On our test scan, page images went from 2550×3300 pixels (300 ppi on a Letter page) to 1700×2200, about 200 ppi.
• Recommended uses the same method, harder. The same pages came out at 1236×1600, about 145 ppi. Text that was real text stays selectable and searchable.
• High is a different method. Each page is rendered to a single image and a new page is built around it. On the test scan that image was 826×1069 pixels, about 97 ppi. Any text layer, form field, or link on the page is gone, because the page is now a picture.

A scanned page has no text layer to lose, so for scans the three levels only differ in how hard they squeeze the picture. A born-digital page, exported from Word, Google Docs, or a design app, is mostly text and vectors. That is where the difference between Recommended and High matters.

Measured: a 10-page scanned lease

We generated a 10-page US Letter “scan”: each page is a 300 ppi color JPEG (quality 90) of typed lease text on a textured paper background, which is roughly what a flatbed scanner writes on its default color setting. The original was 18.9 MB.

Each run took under two seconds. We then rendered page 1 of each output at 100% zoom. The body text, set at about 10 point, was readable in all three. High was visibly softer around the edges of letters. Low and Recommended were hard to tell apart at that zoom. For a scan, Recommended is the sensible default: most of the saving, no visible cost at normal reading size.

If the document will be printed, or someone has to read small print (a stamp, a date next to a signature, 6-point footnotes), start with Low and check the result at 200% before you send it.

Measured: a 12-page text report

The second test file was a 12-page report with an embedded, subset font and no images at all: 35.3 KB. Low and Recommended both returned 31.3 KB, 11% smaller, and the text still extracted cleanly when we checked it with pypdf. High returned the original file with an “Already optimized” label, because the rasterized version was not smaller.

That is the pattern to expect for born-digital documents. There is very little to remove, the file is already far below every email limit, and turning text into pictures would make it worse: larger, blurrier, and no longer searchable. If a text PDF is unexpectedly large, look for the reason (an embedded photo, a pasted screenshot, a scanned signature page) rather than reaching for High.

When High is the wrong button

• Contracts and letters that you or the recipient will quote from. After High, nobody can copy a clause or search for a name.
• Fillable forms. A flattened form is a picture of a form, and the fields stop working.
• Documents with links. Hyperlinks and cross-references disappear with the text layer.
• Anything that has to be accessible. Screen readers need the text layer.

High is for the case where a portal or mail server still refuses the Recommended result and the document is effectively a scan anyway. Use it knowingly.

Check the output before you send it

Image compression is lossy by design, so look at the result:

1. Open the output and zoom to 100%, then to 200% on the densest page.
2. Try to select a sentence. If it selects, the text layer survived.
3. Check the smallest text on the page: footers, stamps, handwriting.
4. Compare the page count with the original.

If the output is not smaller than the input, the result says “Already optimized” and you get the original back, as happened with the text report above.

A file the compressor skips

We also made a PDF with ReportLab in which the image data was wrapped in an extra ASCII85 text encoding around the JPEG. The compressor left it untouched and reported “Already optimized” (1.82 MB in, 1.82 MB out). Most scanner and office exports store JPEG data directly, which the compressor does handle. If a large file will not shrink at all, an unusual image encoding is one possible explanation.

Split before you compress

If a file is large because it has 80 pages and you need three of them, split first. Compressing pages you are about to throw away costs time and memory. A small extract can still carry a large shared image, though: the split guide shows a one-page extract that kept 98% of the original size, and explains why.

How we measured

All numbers on this page were measured on 27 September 2026 with this site’s tools, running in Chrome on a Linux desktop. The test files were generated with ReportLab and Pillow, and outputs were inspected with pypdf, pikepdf, and pdftoppm. Sizes are as the tool displays them (1 MB = 1,048,576 bytes). Your own files will give different numbers; the ratios for scans are typical of JPEG re-encoding, but the result always depends on how the original was produced.