You set a target size, ran Compress PDF, and the result is either barely smaller than what you started with, or the tool tells you outright that it couldn’t hit the number. Neither is a glitch. There’s a real, checkable reason a given PDF has a floor it won’t go under, and knowing what it is tells you whether to keep fighting the compressor or stop and do something else.

Compression shrinks images. Most PDFs aren’t made of images.

Every compression pass here works the same way: render each page to a bitmap, then re-encode that bitmap as a JPEG at some quality level. That’s a great trade when a page is already a photograph — a scanned form, a photographed receipt — because you’re re-compressing something that was large to begin with. JPEG quality has a lot of room to give before it looks bad, and that room is where the file shrinks.

A page of real text is a completely different object. In the original PDF, a paragraph isn’t pixels — it’s a short list of character codes, a font reference, and coordinates. That’s already about as compact as a page gets. Rasterizing it replaces that tiny description with a full-resolution grid of pixels, then asks JPEG to claw back the space text had for free — and often it can’t claw back enough to beat the original. A clean one-page invoice that started at, say, 60KB as text can turn into a JPEG-based page of similar or even greater size, because a full-page bitmap at a readable resolution simply costs more bytes than the text it’s replacing. The floor on a text PDF isn’t the compressor being weak — it’s rasterizing something that had nothing to gain from it in the first place.

Text vs. scanned is the only variable that matters here

Forget how the PDF looks on screen; what matters is what’s underneath it.

  • Scanned or photographed pages have no text layer — they’re already one image per page, usually at a higher resolution and lower JPEG quality than necessary for a screen or a printed copy. Compressing these has real headroom: dropping resolution and quality on an already-a-photo page is close to free, because nothing other than image data was ever there.
  • Text-based pages — anything exported from Word, Google Docs, LaTeX, or typed directly into a PDF editor — store characters, not pixels. There’s very little fat to trim, and rasterizing them is a lossy, one-way move: you permanently lose the ability to Ctrl+F or select text on that page in exchange for a size change that might not even be a reduction.

A quick way to check: try selecting a sentence with your cursor. A highlighted sentence means text, with a low ceiling on how much compression can help. Only being able to select the whole page as one block means it’s an image already, with real room to work.

Compression also throws away everything that isn’t visible ink

The rebuild that shrinks a page doesn’t selectively strip the heavy parts and leave the rest alone — it throws the whole page away and starts over, keeping only a single JPEG picture of it. Nothing else survives that rebuild, because nothing else is a pixel on the rendered page: a hyperlink, a fillable form field, a digital signature, a comment or highlight, the document’s title and author metadata, any font that was embedded in it. All of that is gone in the output, not compressed down, just absent. The page looks identical and prints the same, so this is easy to miss until you go looking for a link that used to work or a form field that used to be fillable. If the original needs to stay clickable, fillable, or signed, compress a copy and hang on to the source file — there’s no setting here that keeps the interactive parts while still shrinking the page.

When the target genuinely can’t be hit

For a photo-heavy file, the tool searches JPEG quality for the highest value that still fits your target, and backs off to a smaller render size only if quality alone can’t get there without turning pages to mush. That process has limits: a 60-page scanned dossier squeezed toward a 200KB target will run out of room no matter how the search is tuned. When that happens, the result screen says so plainly — closest size achieved, target not met — instead of quietly handing you a file that still fails the portal’s check. A “success” on a file that gets rejected anyway is worse than an honest no.

What to do when compression won’t get you there

If the file is text-based, or a scanned file is still over budget after compression, shrinking the image data further isn’t the lever left to pull. A few that actually reduce bytes without destroying the document:

  • Cut the white space you’re not using. Wide margins and unused page borders are real pixels on every rasterized page. Crop PDF trims them before you compress, which can measurably shave a scanned file’s size since there’s less page area to render.
  • Drop pages that add nothing. A blank cover sheet, a blank back page from a duplex scan, a stray instructions page — each one is full page weight for zero content. Remove Blank Pages clears them out automatically.
  • Split instead of shrink. If the destination accepts more than one file — an email, a shared drive, anything that isn’t a single-upload form field — Split PDF breaks a large document into pieces that each clear the limit on their own, with nothing re-encoded or degraded.
  • Go grayscale before you compress, if the document doesn’t need color. A full-color scan of black-ink text or a signature is still carrying three color channels to represent what’s really one channel of real information. Grayscale PDF strips that down first, and the same target size afterward has more room to work with — the result reads sharper at the same file size than compressing the color original straight to that number.

If the destination insists on one file under a hard cap and the document is genuinely text-heavy, that combination has no clean fix — pushing quality lower just produces an ugly, still-too-big file. The honest options are cropping and trimming pages first, then compressing what’s left, or asking whoever set the limit whether a slightly larger file is actually acceptable.

Don’t run an already-compressed file through compression again

If a result comes back a little softer than you’d like, the instinct is to feed that same output back into the compressor for another pass. That makes things worse, not better. Each pass rasterizes whatever it’s handed and re-encodes it as a fresh JPEG — run it on a file that’s already been through this once, and you’re re-encoding a JPEG of a JPEG. The detail lost in the first pass is already gone and doesn’t come back, so the second pass is searching a narrower, lower-quality range for no real size benefit — you end up with something softer at close to the same size, not smaller. If a result isn’t good enough, go back to the original file and try a different target, a lower-resolution rescan, or the cropping/grayscale/splitting steps above — never the already-compressed output.