Why Compressed PDFs Are Still Huge

Most PDF compressors, including browser-based ones, work by re-encoding the JPEG photos embedded inside a PDF at a lower quality. If your file barely shrank, the compressor almost certainly found nothing it was willing to touch — not that compression "failed." A scanned document that's still 40MB after running through a compressor usually means its pages aren't stored as compressible JPEGs at all, or the images were already about as small as they can get without a visible quality hit. Neither is a bug; it's the tool being conservative about not degrading your file for a marginal size win.

A PDF compressor scans the file for image objects and checks how each one is encoded. Only images using JPEG-style (DCTDecode) compression are candidates for recompression — that's the dominant real-world cause of PDF bloat, since scanned pages and photos are usually stored this way. But some scanners and "print to PDF" drivers embed pages as PNG, TIFF, or raw bitmap data instead. Those formats are lossless by design, so a compressor built around re-encoding JPEGs has nothing to work with — it leaves them untouched rather than converting them to a lossy format you didn't ask for.

If a scanned page was saved as a CMYK JPEG (common from some office scanners and print-oriented software), a browser-based compressor will typically skip it entirely. Browsers can't reliably decode Adobe's CMYK JPEG variant through the canvas APIs these tools rely on, and guessing wrong would shift the page's colors — a much worse outcome than a large file. So the safer, correct behavior is to leave CMYK images exactly as they are and only compress the RGB ones it can decode with confidence.

Recompressing an image has a real cost: every pass is lossy, and stacking lossy passes on top of whatever your scanner already applied compounds quality loss. Because of that, a well-built compressor only keeps the recompressed version of an image if it's meaningfully smaller than the original — PixelTools' own compressor requires at least a 10% reduction per image before it swaps the file in. If your photos were already compressed tightly (a modern scanner, a phone camera, a previously-compressed PDF), most images fail that bar and the original bytes are kept untouched. The output file barely changes in size, but every image in it is exactly as sharp as it went in.

"Smallest file," "Balanced," and "Best quality" settings aren't just a vague slider — they set two concrete numbers: a JPEG quality percentage and a maximum pixel dimension the image gets downscaled to before re-encoding. The smallest-file setting pushes images down to 1200px on the long edge at 40% JPEG quality; the best-quality setting caps at 2000px and 75% quality. If your scanned pages are already under those dimensions — a lot of phone-scanned receipts and letter-size pages are — the downscale step does nothing, and you're only getting whatever the quality drop alone saves, which can be small on an already-compressed JPEG.

If your PDF has no embedded photos at all — a Word-exported invoice, a form filled out digitally, a vector diagram — there's simply nothing for an image recompressor to act on. A compressor still re-saves the file with tighter internal object-stream packing, which trims a modest amount of overhead, but that's a few percent, not the dramatic size drop people expect from "compress." A PDF like this being large in the first place is usually about embedded fonts or a bloated page-object structure, not photos, and no image compressor touches either of those.