Why is my compressed PDF the same size as before?

Most PDF compressors only shrink embedded JPEG images. If your PDF is mostly text, vector graphics, or already-compressed images (PNG, or a scan saved with Flate/CCITT encoding), there's nothing for a JPEG re-encoder to touch, so the file comes back close to its original size.

Why did compressing my PDF make it bigger?

Rebuilding a PDF's internal structure (its cross-reference table and object streams) can add a small amount of overhead even when no images changed. If the original file had no compressible images to begin with, that overhead can make the 'compressed' file marginally larger than the source.

What actually reduces a scanned PDF's file size?

A scanned PDF is usually a sequence of full-page images, often saved as PNG or Flate/CCITT-encoded bitmaps rather than JPEG. Shrinking those requires decoding the image, re-encoding it as JPEG (which is lossy but far smaller for photographic content), and rebuilding the PDF around the new image — a different code path than re-compressing an existing JPEG.

Why didn't compressing my PDF make it smaller?

ClientPDF Guide · a 2-minute read

You ran a PDF through a compressor, and the file that came back is basically the same size — sometimes even a few kilobytes bigger. That's not a broken tool. It's almost always one of three specific, checkable reasons.

1. There were no JPEG images to shrink

Nearly every browser-based PDF compressor — this one included — works by finding JPEG-encoded images inside the PDF (technically, image streams using the /DCTDecode filter), decoding them, and re-encoding them at a lower quality setting. That's where the size savings come from. If your PDF is mostly text, vector graphics, or form fields, there are no JPEGs to touch, and the file comes back close to its original size — correctly, not as a bug.

2. The images are PNG or already losslessly compressed

Scanned documents are often saved as PNG, or as Flate/CCITT-encoded bitmaps rather than JPEG. Those formats compress differently, and a JPEG re-encoder won't touch them at all. This is the single most common reason a "compress" button appears to do nothing on a scanned PDF — the tool is working exactly as designed, it just isn't the right tool for that image format.

3. Rebuilding the file added a small amount of overhead

Every PDF compressor has to rebuild the file's cross-reference table and object streams after touching anything inside it. That rebuild costs a few hundred bytes to a few kilobytes. If step 1 and step 2 both found nothing to shrink, that small rebuild overhead is the only thing that changed — which is why an already-optimized PDF can come back very slightly larger than it went in.

How to tell which one applies to your file

If your PDF is a scanned document (a photo of a page, not real text) and didn't shrink, it's almost certainly reason 2 — PNG or lossless-encoded images.
If your PDF is a report, invoice, or form with mostly text and maybe a logo, it's reason 1 — there simply isn't much to compress.
If the size difference is a rounding error in either direction, it's reason 3 — nothing meaningful changed either way.

What actually shrinks a scanned PDF

Scanned pages need to be decoded from their original format, re-encoded as JPEG (lossy, but dramatically smaller for photographic or scanned content), and rebuilt back into the PDF — a different, heavier code path than re-compressing an existing JPEG. That's on the roadmap here; today, ClientPDF's compressor targets the common case — PDFs with existing JPEG images — honestly, and tells you when there's nothing compressible found rather than pretending to have done work it didn't do.

Try it yourself: compress a PDF — DevTools open, Network tab watching. If it says nothing was compressible, now you know why.