Is PDF compression lossless or lossy?

Both, in the same file. Text, vector graphics and fonts are compressed losslessly and come out identical. Photographs and scans are re-encoded and genuinely lose detail. That is why compressing a text document is free and compressing a scan is a trade.

Why did compressing my PDF barely change anything?

Because the lossless layer was already applied when the file was written, and there were no images for the lossy layer to work on. A file that is almost entirely text is already close to as small as it gets.

Does compressing a PDF reduce the print quality?

It reduces image resolution, so for a photo book intended for print, yes, visibly. For a scanned document going to a screen or an office printer, downsampling from 300 DPI to 150 is usually indistinguishable. Text drawn as text is untouched at any setting.

Why is my merged PDF bigger than the two files added together?

Usually fonts. If both files embed subsets of the same typeface under different internal names, the merged file carries both subsets, because nothing can safely prove they are interchangeable. Running a compression pass afterwards often reclaims it.

how does pdf compression work

How PDF Compression Actually Works

"Compress PDF" runs several unrelated operations behind one button. One of them is lossless and usually already done. One of them is where all the size comes from, and it is not free.

Layer one: stream compression, which is lossless and already on

Every stream in a PDF — content streams, embedded fonts, image data — can carry a filter that says how it is encoded. The common one is `FlateDecode`, which is deflate, the same algorithm as ZIP. Text drawing instructions are highly repetitive, so deflate does very well on them: a page of drawing commands routinely compresses to a fifth of its size.

The important part is that nearly every PDF writer applies this at the moment it saves. By the time you have a file, this layer has already run. It is why zipping a PDF gains you almost nothing, and why compressing an already-small text PDF gives you back a file the same size. There was nothing left to take.

PDF 1.5 added two refinements that still help on files that predate them. Object streams pack many small dictionaries into a single compressible stream instead of leaving them as loose uncompressed text. Cross-reference streams do the same for the index. On a large document with tens of thousands of objects, that alone can be a meaningful reduction, and it costs nothing at all.

Layer two: image re-encoding, which is where the size lives

Deflate is useless on photographs. A scan has no exact repetition for it to exploit — every pixel differs slightly from its neighbour — so lossless compression on image data returns close to nothing. Image data is instead stored with `DCTDecode` (JPEG) or, for bilevel scans, `CCITTFaxDecode` or `JBIG2Decode`.

So compressing an image-heavy PDF means one thing: decode each image, change it, and encode it again. There are three levers, and every one of them is a real trade.

Downsampling: Reduce the pixel dimensions. A 300 DPI scan holds four times the data of a 150 DPI one, and a screen cannot show the difference. This is the biggest single win on scanned documents.
Re-encoding quality: Raise the JPEG quantization. Going from quality 95 to 80 typically halves the data and is hard to see; going below 60 starts showing halos around text.
Colour reduction: Convert colour to grayscale, or a grayscale scan of clean text to bilevel. Black type on white paper carries no colour worth keeping.
What it costs: All three are one-way. The discarded pixels are gone, and compressing the result again re-encodes already-degraded data.

Layer three: throwing away things you were not looking at

A surprising share of a PDF is often overhead nobody wants. Fonts are the classic case: a fully embedded font can run to several hundred kilobytes, and a document that uses eleven characters of it in a heading is carrying the entire typeface. Subsetting rewrites the font to contain only the glyphs actually drawn.

Then there is duplication. A logo placed in the header of every page is frequently embedded once per page rather than stored once and referenced eighty times. Deduplicating identical objects on a long report can take a third off the file with no visual change whatsoever.

The rest is smaller but adds up: page thumbnails cached by the writer, XMP metadata blocks, unused objects orphaned by earlier edits, JavaScript, and the full edit history left behind by incremental saves. None of it renders. All of it ships.

Why the same setting gives wildly different results

Because the outcome depends entirely on which layer has anything to do. Run a compressor on a 40 MB scan and it will re-encode 200 images and hand back 4 MB. Run the identical settings on a 400 KB text report and it will find no images, no unsubsetted fonts and no duplicate objects, and hand back 390 KB.

Neither result is the tool working well or badly. It is the same operation meeting two entirely different files, and it is why the first useful question is always what the file is made of rather than how hard to squeeze it.

Generation loss, and why twice is not twice as good

JPEG quantization is not idempotent. Re-encoding an image that has already been quantized re-quantizes coefficients that were already rounded, so error accumulates while the size barely moves. The second pass typically takes a few percent off and adds visible artefacts around every hard edge.

If one pass has not reached your target, the productive move is to change something structural — downsample further, drop to grayscale, remove pages — rather than to run the same compression again.