Compress PDF

What does it mean to compress a PDF?

A PDF is a container: fonts, page descriptions, and embedded images all packed into one file. To compress a PDF is to make that container smaller without changing what a reader sees when they open it — same pages, same text, same layout, same links. That last clause rules out more than it sounds like it does, because the obvious way to shrink any document is to stop treating it as a document. Render every page to a picture and rebuild the file from those pictures, and the size drops a lot; it also stops being a PDF in any way that matters, since the text can no longer be selected, searched, or copied, and every link and form field in it is gone. This tool will not do that trade, on any setting.

Once rasterising is off the table, there are only two levers left, and they are unrelated. One is how the file itself is packaged — the same objects, described more efficiently. The other is how the images inside it are encoded — the same picture, stored in fewer bytes. Running the whole file through a generic compressor first is not a third option; it is not an option at all, because every PDF writer already deflates its internal streams, so gzipping the result on top does nothing.

This tool applies the packaging lever automatically, every time, at no cost to anything in the file, and offers the image lever as a choice with four levels: Lossless, which touches no image at all; Light, which keeps full resolution and re-encodes images gently; Balanced, which caps images at 1600 pixels on the long side; and Strong, which caps them at 1200 pixels and encodes harder. Which of those actually helps depends entirely on what is inside your specific file, which is why the tool shows you the page count, the image count, and the share of the file that is image data before you pick anything.

How to compress a PDF

1. Drop your PDF onto the page. It opens and is read entirely inside this browser tab, and the tool reports its page count, how many images it contains, and what percentage of its bytes are image data.
2. Pick a compression level. Choose Lossless to only rebuild the file's internal structure, Light to re-encode images gently at full resolution, Balanced to cap images at 1600 pixels on the long side, or Strong to cap them at 1200 pixels and encode harder.
3. Read the breakdown, then download. The result shows original size, compressed size, and the percentage saved, split into what came from rebuilding the file and what came from re-encoding images, plus how many images were touched and how many were left alone and why — and if nothing got smaller, there is no download button, just that fact stated plainly.

The lever nobody mentions: rebuilding the file itself

Before any image is touched, this tool re-serialises the file's objects using cross-reference streams and compressed object streams — a PDF 1.5 feature that files saved by older software never took advantage of. It costs nothing and it changes no content, but on the right file it is worth more than most people expect from a setting they never had to choose.

Measured on three real published PDFs with no image touched: the CSS 2.1 specification, saved originally as PDF 1.4, went from 1,424,897 bytes to 841,245 — 41.0% smaller. An arXiv paper, saved as PDF 1.5, went from 2,215,244 to 1,825,255 — 17.6% smaller. A NIST Special Publication, already saved as PDF 1.6 with compressed object streams in use, went from 2,027,518 to 2,017,098 — 0.5% smaller, because there was nothing left on the table. The rule the numbers show is simple: the older the file's format, the more this step alone is worth, and on a file already written efficiently it will honestly tell you there is little to gain here.

That this rebuild is lossless was checked rather than assumed. All three re-saved documents came out with the same page count, the same number of indirect objects — 5,928 went in and 5,928 came out for the CSS specification, so nothing was dropped — the same fonts and images, the same annotations (all 3,489 links in the CSS specification survived), and every page's decoded content stream byte-identical to the original. As a second check, saving the same three files with compressed object streams switched off produced a file bigger than the original in two of the three cases, which confirms the saving comes from how the objects are encoded, not from anything being quietly removed.

How much further compression can go from there depends on how much of the file is images rather than text: 10.5% of the CSS specification's bytes are image data, 8.9% of the arXiv paper's, and 30.1% of the NIST report's. A file that is mostly text, like the first two, gets almost all of its saving from the rebuild alone. A file that is a third images has real headroom left in the image lever described next.

What this tool won't do, and why it sometimes gives you nothing

Not every image in a PDF gets touched, and each exemption is a deliberate one rather than a gap. Bitonal scan formats — CCITT fax and JBIG2 — are already smaller than any JPEG this tool could produce from them, so they are left alone because they are already better than the alternative. JPEG 2000 images are skipped because no browser can decode them. CMYK images, in any of the several ways PDFs store them, are left alone because browsers decode CMYK JPEGs inconsistently and some invert their colours outright — quietly wrecking a print file's colour is a worse outcome than not shrinking it. Soft masks are left alone because a mask is another image's alpha channel and must stay greyscale by specification, while any re-encode this tool does comes back in colour. And indexed palettes, one-bit stencils, and anything under 8 KB are skipped because at that size the round trip is as likely to grow the image as shrink it.

The format an image is stored in matters more than it sounds like it should. Across those same measured documents, 98% of image bytes were plain Flate-compressed pixels rather than JPEG, so a tool that only handled JPEG images would have done nothing to any of them. This one inflates those images, undoes their row predictor, and hands the raw pixels to the same encoder, which is the only reason the image lever reaches most real documents at all.

Even among images this tool is willing to touch, re-encoding does not automatically make them smaller, and the tool checks rather than assumes. A 433 KB photographic JPEG re-encoded at quality 0.82 came back at 537 KB; the same source re-encoded at quality 0.65 came back at 447 KB — both bigger than the original. Nearly all of the real saving on a photo that is already a JPEG comes from scaling it down, not from re-encoding at the same size: capping that same photo to 1200 pixels on the long side brought it to 202 KB. Because of this, an image is only ever replaced when the replacement is actually smaller than what it started as.

Lossless images get an extra bar to clear, because trading a lossless stream for a lossy one throws away information the file had. Across the three measured PDFs, all nine lossless images were diagrams and charts, and re-encoding every single one as a JPEG made it bigger — between 1.42 and 4.22 times its original size, because flat colour is exactly what the original lossless encoding is good at and exactly what JPEG is bad at. Two real photographs, stored the same lossless way and measured separately, came back at between 0.045 and 0.121 of their original size instead. There is an order of magnitude of clear space between those two groups, and this tool only replaces a lossless image when the saving falls on the far side of it.

The same honesty applies to the whole file. A document that is mostly text cannot be meaningfully compressed by anyone, rebuild included, and if the result is not smaller than what you started with, this tool does not hand you a file that merely claims to be compressed. There is no download button in that case — just the reason why, rather than a re-save dressed up as a saving.

Why is it free?

Everything above happens inside your browser tab: the file is opened, inspected, rebuilt, and — if you choose — its images are re-encoded, all on your own machine. Nothing is ever uploaded to a server, so there is no file size limit tied to an upload, no account to create, and no watermark stamped on the result, because there is no server-side step where one could be added. That is also why this page costs nothing to run: the only expense is serving the page itself, not processing your files.