Herramientas · PDF · Comprimir PDF · Guías · How to Shrink a PDF Without Losing Readability
How to Shrink a PDF Without Losing Readability
Here's the actual process for shrinking a PDF with Compress PDF, and what's really happening behind the two presets.
Step 1 - drop the PDF
Choose or drag in the file, up to 80 MB. There's nothing to configure before this - the tool needs the file loaded before it can tell what's actually inside it.
Step 2 - pick a preset
Recommended, selected by default, re-encodes embedded JPEG images at a quality setting that keeps pages looking the same at normal viewing size. Smallest file goes further - a lower quality setting plus capping any oversized image down to a 1600px long edge - trading a little sharpness, visible only if you zoom in close, for the smallest file the tool can produce. On a typical scanned document, Recommended comes down about 45% smaller and Smallest file around 75% smaller - real numbers from testing this tool, not a guess, and results vary with how the original was scanned.
Step 3 - compress and download
Click Compress. The tool walks every page looking for embedded JPEG images, recompresses each one it finds at the chosen preset's quality, and rebuilds the PDF around the smaller versions. A very large embedded image is capped at a 4000px long edge regardless of which preset is chosen - not a quality lever, just a guard against a single oversized scan straining memory on a phone.
What happens with a text-only PDF
Some PDFs have nothing to compress - a document that started as typed text, with no scanned or photographed pages, has no oversized embedded images sitting inside it. This matters more than it sounds: a naive compressor that blindly reloads and re-saves every PDF, whether or not it finds anything to shrink, can make a text-only file larger - in testing, a bare load-and-save on a real 400-page, zero-image PDF grew the file by about 41%, purely from PDF-internal bookkeeping overhead with nothing gained in return. This tool checks for embedded JPEG images before doing anything else, and when a document has none, it hands back the exact original file, byte for byte, rather than rebuilding something that didn't need rebuilding. You'll see an honest message saying there was nothing to compress, not a fake "0% smaller" result presented as if it were a success.
The same safety net applies to images that are already small
Even when a document does have embedded images, if recompressing them doesn't save at least a few percent, the tool discards the recompressed attempt and returns the original instead. That's what makes running the tool twice on its own output safe - the second pass finds nothing worth doing and returns what you already had, rather than "compressing" an already-compressed file into a slightly different, not-actually-smaller version just to look like it did something.
What this doesn't touch
Only images stored as a single, plain JPEG stream inside the PDF are recompressed. Other image formats a PDF can embed - raw uncompressed images, or images stacked behind multiple compression filters - are left exactly as they are. This is a deliberate, narrower scope: the JPEG case is by far the most common one in real scanned documents, and touching the rarer cases well would need meaningfully more engineering for a small slice of files.
Nothing here goes to a server
The PDF you drop and the compressed file you download both stay in the browser the whole time - there's no upload step, and the 80 MB size limit is there to stay inside your browser's memory, not a server quota.
For why scanned PDFs end up this large in the first place, see the background. To pick a preset against a specific size limit, this guide covers that directly. Or compress a PDF now.