Why did compressing my PDF make it bigger?
A 6 MB PDF went into a compressor. What came back was 6.4 MB. Not "barely smaller", which you were half expecting — actually larger than the thing you uploaded.
So you tried the hard setting, on the theory that it would at least go the right way. 7.1 MB. Then a different site, which produced 6.9 MB and a watermark.
Search for what happened and every result answers a question you did not ask: why is my PDF so big. You know why it is big. You want to know how squeezing something made it heavier, because that is not how squeezing is supposed to work.
Compression is a bet, and it is not always won
A PDF compressor does not squeeze the file the way a zip does. It takes the document apart, re-encodes some of the pictures inside it, and writes a new file around the result. Every one of those steps is a bet that the new encoding comes out smaller than the old one.
The bet is usually won, because most oversized PDFs contain a photograph stored at far more detail than the page can show, and throwing away detail always pays. But there are four situations where it loses, and a tool that does not check its own result afterwards will hand you the loss.
Two of them are about the pictures. Two of them have nothing to do with the pictures at all.
The picture was already a JPEG
Decoding a JPEG and encoding it again is not a free round trip. It is a second lossy pass over an image that has already been through one.
The first pass left its own marks: faint blocking along the 8×8 grid the encoder works in, and ringing round hard edges. Your eye skates over those. The second encoder cannot. It has no idea they are artefacts rather than content, so it spends bits reproducing them faithfully — and blocky, ringing edges are high-frequency detail, the most expensive thing a JPEG can be asked to store.
On top of that, quality numbers do not mean the same thing in two different encoders. "Quality 70" in the library your compressor uses may well be more generous than the setting your scanner or camera used. You asked for a lower number and got a bigger file, because the number was never a common currency.
The net result is an image that looks slightly worse than the original and weighs slightly more. That is the single most common way a compression run goes backwards.
The picture was flat colour, and it got turned into a photograph
The other image case is sharper, and it is what usually produces a file that grew by half rather than by three per cent.
Screenshots, charts, diagrams, logos and line drawings are stored losslessly, as Flate — the same algorithm as a zip file. Flate is superb on flat colour, because a run of four hundred identical white pixels costs almost nothing to record. A 60 KB PNG screenshot of a spreadsheet is 60 KB precisely because most of it is the same colour repeated.
JPEG has no concept of "the same colour continues". It divides the image into blocks and stores frequency coefficients for each one, which is an excellent way to describe a face and a terrible way to describe a black line on white. Hard edges need almost every coefficient, and the ones that get dropped come back as grey haze round your text. So the screenshot leaves as a 250 KB JPEG that also looks smeared, and the compressor reports a successful conversion.
The extreme version is a scan. A one-bit black-and-white page written by the scanner in CCITT or JBIG2 can be 30 KB; re-encoded as a JPEG at the same pixel dimensions it is several hundred. That is the same mechanism that makes an edited scan balloon to ten times its size, and it is worth reading if your file is a scan, because the fix there is different.
If your document is mostly screenshots, this is also the setting advice: raise the resolution ceiling to 300 and use the gentle level. Screenshots are usually drawn at close to their stored size, so there is little to reclaim by scaling them, and the ringing round the text is what you pay.
Working out which picture did it
Two minutes, before you try a fifth tool.
Run Extract images from PDF with the format left on as they are in the file. Pictures
the PDF holds as JPEGs are handed over as those exact bytes, and everything else comes out as PNG, so
the extensions in the zip tell you what you are dealing with: a .jpg was already a JPEG, and
re-encoding it is the losing bet above. A .png that is a screenshot or a chart is the other one.
Sort by size and look at the top three.
Our PDF inspector fills in the rest without uploading anything: page count, page sizes, whether the document is tagged, and which program produced it. The producer line matters here more than it looks — it names the tool that last rewrote the file, which is often the tool that made it bigger.
What a compressor should do when it loses the bet
Check the result, and throw it away if it is worse than what it started with.
Compress PDF checks twice. Each picture is compared against the one it replaced, and if the new version is not smaller the original picture stays in the document. Then the finished file is compared against the file you uploaded, and if that is not smaller either, you get your own bytes back with a note saying so. It also never takes the losing bet in the first place on an image that is already a JPEG and already at or below your resolution ceiling — such an image is left completely alone.
That is why a run here sometimes reports no change at all. No change is the honest outcome of a bet that could not be won. A larger file is a tool that took the bet, lost, and handed you the loss.
When the pictures were never the problem
Now the two causes that have nothing to do with images, which is why they baffle people who have already checked that their photos are fine.
The structure was rewritten less efficiently than it was written. A modern PDF packs its thousands of small objects — every page dictionary, every annotation, every entry in a bookmark tree — into deflated object streams, with a compressed cross-reference stream to index them. A tool that writes each of those objects out on its own, followed by a classic cross-reference table, produces exactly the same document and a much larger file. On a tagged document this is brutal, because tagging means one small dictionary per paragraph, per list item, per table cell: tens of thousands of objects that were sharing one compressed stream and are now sitting in the file individually. The tell is that nothing visible changed, no image count changed, and the PDF version in the header went down.
The save appended instead of replacing. A PDF can be updated incrementally: the changed objects are written on the end and the original ones stay exactly where they were. Nothing points at the old copies, nothing renders them, and they are all still in the file. If the tool preserved a digital signature, it had no choice — that is the only way to change a signed file without breaking the signature. A form saved thirty times carries thirty of these layers, and compressing it by appending a compressed copy is how a file grows every single time you try to shrink it.
Repair PDF is the tool for that second one. It rebuilds the document page by page into a fresh file, so anything unreachable is left behind by construction. It is not a compressor and does nothing to a healthy file, but on a much-edited form it removes more than compression ever could. A digital signature will not survive the rebuild — that is the trade.
Neither of these is something our own tools do to you. Every save here writes object streams and a compressed cross-reference stream, and none of them appends. The inspector will not tell you whether your file has incremental updates in it, though; that is not something it reports.
What this will not do
It does not subset or re-embed fonts, so a file whose weight is in its typefaces will not move. It re-saves a repeated picture once when the document genuinely shares one object, but two byte-identical images stored separately stay as two. It cannot open an encrypted file. And if you ran our Greyscale PDF tool and the file grew, that is expected rather than a failure — it is a printing tool that redraws every page as an image, and the reason it inflates a text document is covered in the post on a PDF that refuses to shrink, along with the qpdf and Ghostscript routes for a file whose size is structural.
The one desktop command worth adding
For a file that grew from incremental saves or a clumsy structure rewrite, MuPDF's command line tool is the cleanest answer, and it touches no image at all:
mutool clean -gggg -z in.pdf out.pdf
The four gs garbage-collect unreachable objects, compact the cross-reference table, and merge
duplicated objects and streams; -z deflates anything left uncompressed. Nothing is re-encoded, so
nothing can come out looking worse. mutool info in.pdf is also the quickest way to see the fonts and
images a file is actually carrying, and how each image is encoded.
If none of that moves the number, the file is telling you the truth: there is nothing in it that this kind of compression can take.