Merged PDF Bigger Than the Originals? Why

A merged PDF is bigger than each of its inputs because it holds all of them, and it should land at or just under the sum of their sizes, not above it. PixelTools' merge tool copies every page from every file into a new document and saves it once. We checked this by merging Chrome-made test PDFs with pdf-lib 1.17.1, the library the tool uses, through the same page-copy calls. Two text PDFs of 23,934 and 24,899 bytes (48,833 total) merged to 39,736 bytes. Two photo PDFs of 625,094 and 624,591 bytes (1,249,685 total) merged to 1,243,369. We did not produce a case where the merged file came out larger than the sum. If yours does, the cause is usually in the inputs, covered below.

Across five merges the output was always a little smaller than the inputs added together, by 0.3 percent to 20 percent. The text pair shrank 18.6 percent (48,833 to 39,736 bytes). A photo PDF merged with a 482,939 byte image-only PDF made with ImageMagick went from 1,108,033 to 1,104,328 bytes. All five test files together, 1,781,457 bytes, merged to 1,763,828. The saving is small because the page data, fonts and images are copied as they are; the tool just rewrites the file structure and saves it with compact object streams, which pdf-lib does by default. Even two blank pages (583 bytes each) merged to 594 bytes, bigger than either input but far below their 1,166 byte total.

The real reason a merge feels heavy is that nothing is shared between files. Each input arrives with its own copy of its fonts and images, and the merge keeps every copy. Our merged text file listed four embedded font entries where each source listed two, even though both used the same DejaVu Sans. Putting the same text into one document and printing it once gave 30,761 bytes, against 39,736 for the merge of two separate files, so the merged file was about 29 percent larger than a single-pass equivalent (the two layouts differ by one page, so treat the figure as rough). Images behave the same way: two PDFs carrying the same 1200 x 900 photo kept both copies and came to 1,243,369 bytes.

Merging pages that were split apart earlier repeats the font cost on every page. We printed a 63-page text document (85,020 bytes) and split it into 63 one-page files, each about 9,900 bytes because each carries its own font data. Together they were 625,181 bytes, and merging them back gave 497,699 bytes, almost six times the original. Merging that 85,020 byte file on its own returned a 62,066 byte file, so the tool does not blow up a normal document. If your inputs are scans saved page by page, or exports from a tool that makes one PDF per page, expect the output to scale with the number of files.

Forum threads about merged PDFs growing mention duplicated fonts, which we confirmed, and tools that redraw pages onto a new canvas, which does not apply here: the page-copy method keeps each page's own size, as covered in our page size article. Some Adobe community answers say Acrobat can keep a single copy of a shared font, so its merged file can come out smaller than the sum. We did not test Acrobat, and pdf-lib did not do this in our runs. We also could not test scanned files against digital ones as a pair, only image-only versus text-based test files, so we make no claim about typical scan sizes.

Run the merged PDF through a compressor, but set expectations by file type. PixelTools' compress tool, by its own code comment, recompresses embedded JPEG images, which is where most bloat in photo-heavy or scanned files comes from, and skips CMYK JPEGs. A text-only PDF has few images, so it gains little beyond the compact saving the merge already applied; the code comment calls a small result there an honest result, not a bug. We could not run the compressor in Node because it needs a browser canvas, so we have no measured before and after for it. Also remove files you do not need before merging, and avoid merging the same file twice, since each copy is kept in full.