Compress multiple PDFs into one

Why the order matters

Say the mail system stops at 10 MB and you have five documents. Compressing each one to 2 MB and then merging them does not give you a 10 MB file. It gives you something near 10 MB, over or under by an unpredictable amount, because merging is not addition. The five files carry duplicate font programs and shared structure, and the merged document keeps one copy of what it can.

Merging first turns five unknowns into one known. The compress step then sees the actual document and works against the actual number, and the four methods get to look at the whole thing at once rather than at five fragments in isolation.

It also costs less quality. Compressing five times means five rounds of image re-encoding, and a JPEG re-encoded twice is worse than the same JPEG encoded once at the same setting. One pass over the merged file is one round.

Step one, merge

The merge tool takes two or more PDFs, lets you set the order, and writes one document. Nothing is re-rendered, so text stays selectable, and pages keep the size they had, which means a mixed stack of A4 and Letter pages stays mixed.

Set the order in the tool rather than trusting the file names. Scanners and phones name files in ways that sort badly, and one reversed pair is invisible until the person you sent it to finds it. The merging guide covers the order problem in detail.

Step two, compress once

Open the merged file in the compress tool, type the size limit you were given, and run it. Four methods race for the number and the smallest verified result wins. If none of them reaches it, you get the smallest file that passed verification plus the size it did reach, which tells you how far off you are.

The merged document often gives the structural and font methods more to work with than any single source did, because duplicate objects and repeated font programs across the sources collapse into the rebuilt file. How much that saves depends entirely on how similar your sources were, and there is no bench figure for merge-then-compress specifically. The 120 case public run measured single documents.

Check the merged file before you compress it

Open the merged document and look at the page order, the first page of each part and the last page of the file. Merging is reliable. The order you gave it is the part that goes wrong, and it is far cheaper to fix before the compression step than after.

Look for duplicates too. A stack of scanned documents often carries the same cover sheet or the same blank separator page several times over, and those pages cost bytes in the merged file for no reason. Organize pages removes them without rebuilding the document.

Then compress. If you fix the page order afterwards instead, you rewrite the compressed file and pay for a second pass over everything in it.

When one file is the wrong answer

Merging is not always right. If the parts get read separately, or one part gets replaced every month, or the merged result is 300 pages that nobody scrolls through, send the parts. A limit of 10 MB is easier to satisfy with three files than with one.

And if the merged file still misses the target after compression, the fastest saving is usually not a setting. It is dropping the pages that did not need to be in there. The general compression guide covers what makes a file heavy, and the compress hub lists the rest of the cluster.