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 parts do not sum to the whole.

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 the parts first means every image goes through one round of re-encoding before the merged pass even starts. One pass over the merged file keeps image re-encoding to a single round at most.

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 gives the four methods the whole thing at once rather than five fragments in isolation. How much that saves depends entirely on your sources, and there is no bench figure for merge-then-compress specifically. The documented pilot behind the parent page measured single documents: 19 compressions on 10 locally built files in September 2026 at the default setting.

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 can carry 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.

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.