How to Merge and Compress a Stack of PDFs Without Losing Quality

Do the two jobs in the right order

Merging and compressing solve different problems, and it is tempting to run whichever tool you find first. Merging is a structural operation. Every page object from every source file is copied into the new document as it was, with the same fonts, the same vector art and the same image data. Nothing is rasterised, so nothing is lost. Compressing works the opposite way. It re-encodes the raster images inside a PDF at a lower quality to make the file smaller, and that step does lose some detail by design.

The order that keeps the most quality is merge first, then compress once, on the finished bundle: start with Merge PDF, check the page order (and fix it with Organize PDF if a file came in the wrong way round), and only then open Compress PDF on the single file. If you compress each source file separately and then merge the results, a photo that appears in two of the source files gets re-encoded twice for no reason, and you lose the chance to deduplicate a repeated image, such as a letterhead logo on every page, across the whole set. Merge first, and compression only has to touch the raster content once, at the level you chose for the final document.

What merging does not touch

Merge PDF copies pages as complete objects rather than repainting them, so text stays selectable, embedded fonts stay embedded, and images keep their original resolution. Each source file becomes a bookmark named after itself by default, so a fifty-page bundle assembled from ten contracts still has a rough table of contents. Interactive form fields are flattened before copying, because two copies of the same form sharing one field name would otherwise collide. That is worth remembering if one of the files in your stack still needs to stay fillable.

None of this changes the file's size in any meaningful way. Merging several PDFs produces a file close to the sum of the originals, because combining pages is not a compression step. If the combined file needs to fit an email attachment limit or a portal's upload cap, that is a separate job, and it comes next.

What compressing shrinks

Almost all of the weight in a large PDF comes from raster images, not from text. A page scanned at 300 DPI is several million pixels; the text on the same page, if there were any, would be a few kilobytes. Compress PDF re-encodes those images as JPEG at one of three quality levels. Light keeps 300 DPI and quality 85, Recommended drops to 150 DPI and quality 65, and Extreme goes to 96 DPI and quality 45. Anything drawn larger than the level allows is resampled. Text, fonts, vector drawings, links and form fields are copied across untouched, just as in a merge.

This is also where the deduplication happens. An image repeated across many pages of the merged bundle, that same letterhead, is stored once instead of once per occurrence, on top of whatever the per-image re-encoding saves.

Picking a level for a merged bundle

Recommended is the right default for most merged bundles headed to an inbox or a portal. 150 DPI reads well on a screen and the file drops substantially in size. Reach for Light instead when the bundle will be printed or read closely, a set of architectural drawings for example, since 300 DPI is the print standard and quality 85 keeps scanned type crisp. Extreme is worth it only against a hard size ceiling. Photographs turn visibly soft at 96 DPI, though scanned text usually stays legible.

When compressing a merged bundle barely helps

A bundle assembled entirely from word-processed contracts and typed letters has almost nothing raster in it to begin with. Text, fonts and vector drawing instructions are already compact inside a PDF, and re-encoding images that were never there does nothing. If your merged file barely shrinks after compression, that usually means it was mostly text already, not that something went wrong. The bundles that shrink the most are the ones built from scanned pages or photographs, where the pixels were doing all the work.