Why a “compressed” PDF sometimes gets bigger
2026-09-19 · 6 min read
You dragged a PDF into a compressor expecting a smaller file, and the number went up instead. That is not a bug. It is a clue about what your document is actually made of.
The frustration is real: compression is supposed to shrink things. But a PDF is not a single blob that gets squeezed. It is a container holding several kinds of content, and each kind behaves completely differently when a tool tries to make it smaller. Once you know which parts are heavy and which are already tiny, the mystery of the growing file dissolves.
What actually takes up space in a PDF
Open almost any large PDF and inspect where its bytes go, and one thing dominates the ledger: raster images. A single full-page scan at 300 dots per inch is millions of pixels, and even after JPEG encoding it can weigh more than every letter of text in a hundred-page report combined. Text and vector graphics, by contrast, are stored as instructions ("draw this glyph here, stroke this line there"), which are astonishingly compact. Fonts add a fixed, modest cost. Metadata is usually a rounding error.
| Content type | Typical weight | Can compression shrink it? |
|---|---|---|
| Embedded raster images (scans, photos) | Often 80–99% of the file | Yes, this is where real savings live |
| Selectable text | A few kilobytes per page | Barely, already close to optimal |
| Vector graphics (logos, charts, lines) | Small; scales with complexity | No meaningful gain, and risk of harm |
| Embedded fonts | Tens to a few hundred KB, fixed | Only by subsetting, not by re-compressing |
| Metadata and structure | Usually negligible | Lossless tidy-up only |
The lesson from that table is blunt: if your PDF is mostly text and vectors, there is almost nothing for an image compressor to grab. There is no fat to trim, so any tool that promises a smaller result has to invent savings that were never there.
Why re-compressing can add bytes
Here is the part people rarely hear. Many browser and app compressors work by rendering each page to a fresh JPEG and rebuilding the document from those pictures. That approach is spectacular on a chunky scan. On a crisp, text-based PDF it is a disaster in slow motion: a page that was a few kilobytes of sharp vector text becomes a full-resolution photograph of that text. The image needed to keep the letters readable is often larger than the original instructions it replaced. You have traded something efficient for something bulky, and the file grows.
Even on images, re-compression is not free. JPEG is lossy, and every pass throws away a little detail while adding its own encoding overhead. Run an already-JPEG-compressed scan through another JPEG pass ("double JPEG") and you can end up with more artifacts and, depending on the quality setting, no smaller a file. If the source was already saved near the compressor's target quality, the second encode simply repackages the same data with fresh overhead on top.
Lossy versus lossless, and why it matters here
Two genuinely different jobs hide behind the word "compress." Lossless optimization rebuilds the file's internal plumbing, deduplicating objects, packing cross-reference tables, dropping the dead weight that editors leave behind after repeated saves, without altering a single visible pixel or letter. Lossy compression actually changes the content, most often by downsampling and re-encoding images to a lower quality. The first can never make a page look worse; the second trades fidelity for size. Confusing the two is exactly how people end up surprised by a bigger file.
On this site the two live in separate tools by design. The Optimize PDF tool is the lossless one: it tidies structure and leaves text selectable, so it is the safe first move for any document. The Compress PDF tool is the lossy, image-based one built for scans and photo-heavy files. Both run entirely in your browser with nothing uploaded, and both are honest enough to tell you when they cannot beat your original rather than hand back a padded copy. The companion walkthroughs, how to optimize a PDF and how to compress a PDF, spell out which to choose.
What to do instead of blindly re-compressing
When a file refuses to shrink, work from lightest touch to heaviest, and stop the moment you hit your goal:
- Optimize losslessly first. Run the file through a structural pass. If it was bloated by incremental saves or a sloppy exporter, you get real savings with zero quality cost. If it does not budge, you have learned something valuable: the size is in the content, not the packaging.
- Find out what is heavy. A twelve-megabyte file with one embedded photo behaves nothing like a twelve-megabyte file that is a hundred pages of scanned paper. The former needs one image handled; the latter needs a genuine down-res across every page.
- Only then reach for lossy compression, and only if the weight is truly in images. This is where re-rendering pages pays off instead of backfiring.
- Delete what you do not need. Nothing beats removing pages that never had to be there. Trimming blank scans, duplicate cover sheets, or an appendix nobody reads shrinks a file with no quality trade-off at all.
There is also a quiet truth worth accepting: some PDFs are already as small as they are going to get. A ten-page contract full of selectable text might sit at 80 KB, and no compressor on earth will meaningfully beat that. When a tool reports "already optimized," believe it: that is a well-built file, not a failure.
When you have a hard number to hit
Understanding why a file grew is one thing; being told an attachment must be under a fixed cap is another. If you are staring at a bounce message because your document is too large to send, the same principles apply but the tactics get more targeted: walking a file down to a specific size, or splitting it when a single document simply cannot shrink far enough. That playbook has its own home: how to get a PDF under an email attachment limit. Start with the right mental model here, and that guide will make a lot more sense.