Why Compressing a PDF Sometimes Makes It Bigger (and What Ghostscript's -dPDFSETTINGS Does)

One of the more confusing bug reports I get on my file tools goes like this: "I compressed my PDF and it got bigger." The first time I saw it I assumed a bug. It wasn't.

Some PDFs are already about as small as they can get, and running them through a compressor that rebuilds the file can add bytes rather than remove them. Here's why that happens, what Ghostscript's presets actually change, and how I decide which approach to use.

What takes up space in a PDF

Before compressing anything, it helps to know what you're compressing. In most real-world PDFs, the size comes from three things:

• Images. Scans, photos and screenshots. In a scanned document they're nearly the whole file.
• Fonts. Embedded font programs, sometimes complete fonts rather than just the glyphs that are used.
• Structure and content streams. Page drawing instructions, cross-reference tables and metadata. Usually small, but bloated in files produced by some exporters.

You can get a rough picture with poppler's pdfimages:

pdfimages -list input.pdf

This prints every image with its pixel dimensions, encoding, and its resolution as placed on the page (the x-ppi and y-ppi columns). A 300 ppi JPEG on every page tells a very different story from a text-only file with 2 MB of embedded fonts.

Why a "compressed" PDF can come out larger

1. The images are already compressed well. JPEG is lossy. If the source already holds moderate-quality JPEGs, re-encoding them at a similar quality saves almost nothing. If the tool decodes and re-encodes at a higher quality setting than the original, the output gets larger.
2. The file was rebuilt, not optimised. Ghostscript doesn't edit your PDF. It interprets every page and writes a brand-new file with its own pdfwrite device. That means fonts get re-embedded and subset its way, and drawing operations get rewritten. For a lean, well-made PDF, the rewritten version can be a little heavier than the original.
3. Object streams went away. Modern PDFs can pack many small objects into compressed "object streams". A tool that writes the old-style layout, one uncompressed object at a time, can make the structure noticeably larger even though the content hasn't changed.
4. Lossless images got converted. Some tools switch images between encodings. Flate-compressed screenshots with large flat areas of colour can grow when converted to JPEG, and look worse too.

So "compress" isn't one operation. It's a choice between rewriting structure losslessly and resampling images lossily, and the right choice depends on the file.

What -dPDFSETTINGS actually changes

The usual Ghostscript compression command:

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
  -dPDFSETTINGS=/ebook \
  -dNOPAUSE -dQUIET -dBATCH \
  -sOutputFile=output.pdf input.pdf

-dPDFSETTINGS is a bundle of many lower-level parameters. The one that matters most for size is image downsampling resolution:

Downsampling only kicks in when an image's effective resolution is above the target (with some tolerance), so /ebook on a file whose images are already 150 dpi won't shrink those images further. That's case 1 again.

The presets also affect colour conversion, font embedding and JPEG quality. If you want control instead of a bundle, set the parameters directly:

gs -sDEVICE=pdfwrite -dNOPAUSE -dQUIET -dBATCH \
  -dDownsampleColorImages=true -dColorImageResolution=120 \
  -dDownsampleGrayImages=true -dGrayImageResolution=120 \
  -dColorImageDownsampleType=/Bicubic \
  -sOutputFile=output.pdf input.pdf

Lossless first: qpdf

If a PDF is text-heavy or already has sensible images, I try a lossless structural pass before Ghostscript:

qpdf --object-streams=generate --compress-streams=y \
  --recompress-flate --compression-level=9 \
  input.pdf output.pdf

This packs objects into object streams and recompresses Flate data at the highest level. It never touches image pixels, so quality is identical. Savings are often modest, but you never get a worse-looking file.

A script that refuses to make things worse

This is the logic I trust most: try the candidates and keep whichever output is smallest, including the original.

#!/usr/bin/env bash
set -euo pipefail
in="$1"; out="${2:-compressed.pdf}"
tmp=$(mktemp -d); trap 'rm -rf "$tmp"' EXIT
cp "$in" "$tmp/original.pdf"
qpdf --object-streams=generate --compress-streams=y \
  --recompress-flate --compression-level=9 \
  "$in" "$tmp/qpdf.pdf" || true
gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH \
  -sOutputFile="$tmp/gs-ebook.pdf" "$in" || true
best=$(ls -S "$tmp"/*.pdf | tail -n 1)
cp "$best" "$out"
echo "Kept $(basename "$best"): $(stat -c %s "$in") -> $(stat -c %s "$out") bytes"

ls -S sorts by size with the largest first, so tail -n 1 gives the smallest. On macOS, swap stat -c %s for stat -f %z.

The || true keeps the script going if one tool fails on an unusual file, and in that case the original is still a candidate.

Always look at the result, not just the number. A /screen file at 72 dpi can be tiny and also unreadable when printed.

Does compression reduce quality?

It depends entirely on which kind of compression you use. Lossless structural compression (qpdf, Flate recompression) doesn't. Downsampling and re-encoding images does, and how visible that is depends on the target resolution and how the document will be used.

I wrote a longer explainer on whether compressing a PDF reduces quality that goes through it case by case. If you'd rather not keep Ghostscript flags in your head for one-off files, I also built a free Compress PDF tool on OneFileKit that needs no sign-up.

Wrapping up

• Find out what's big first: pdfimages -list tells you most of the story.
• Ghostscript rebuilds the whole file. Great for scans, sometimes worse for lean PDFs.
• -dPDFSETTINGS is mostly about image resolution: 72, 150 or 300 dpi.
• Try a lossless qpdf pass, compare the outputs, and keep the smallest one, which may be the original.

Have you seen a PDF that got bigger after compression? I'd like to know which tool and preset did it.