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.

How do I compress a PDF to an exact size like 100KB or 1MB?

Use the target-size option on ClientPDF's compress tool: pick Under 100 KB, Under 500 KB, Under 1 MB, or Under 5 MB instead of the default best-quality setting, and it automatically re-runs the JPEG re-encode at progressively lower quality and image dimensions until the output fits your target or hits a quality floor.

What if my PDF can't be compressed small enough to hit my target?

If the smallest version reachable without severe quality loss is still over your target, ClientPDF tells you plainly and gives you that smallest version rather than pretending it hit the number. This almost always means the file has little or no compressible JPEG content to begin with — see the reasons above.

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.

How to compress a PDF to an exact size (100KB, 1MB, etc.)

Everything above explains why a fixed-quality compressor sometimes doesn't move the number at all — but if you actually need the file under a specific size (a 1MB email attachment limit, a 100KB form upload cap), guessing at quality settings and re-running the tool by hand is tedious. ClientPDF's compressor now has a target-size option for exactly this: pick "Under 100 KB," "Under 500 KB," "Under 1 MB," or "Under 5 MB" instead of the default "No target — best quality," and the tool re-runs the same JPEG re-encode pass with quality and max image dimension stepped down in stages — 0.65 → 0.5 → 0.35 → 0.3, image edge capped at 1600px → 1200px → 900px — checking the real output size after each pass, until it fits or hits a quality floor.

If the file still can't reach your target at that floor without visibly damaging the images, the tool says so directly and hands you the smallest version it could produce, rather than silently returning something over your limit or faking a number. As explained above, this only works on PDFs with compressible JPEG content in the first place — a text-only PDF or one that's already PNG-encoded won't shrink further no matter how many passes it runs.

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