Merging PDFs without losing what is inside them
A contract, its two annexes and a signed page, sent as four files, is a thing that exists mainly to annoy the person receiving it. Merging fixes that in one step. But "merge" hides a decision about everything in the file that is not a page, and most tools make that decision silently.
What a merge actually does
A PDF is not a sequence of pages the way a text file is a sequence of lines. It is a set of numbered objects, and a page is an object that points at other objects: content streams, fonts, images, colour spaces. Those objects are numbered, and the numbers are referenced from inside other objects.
To combine two files, you cannot just concatenate them. Object 7 in the second file has nothing to do with object 7 in the first. So a merge walks the page tree of each source, copies every object the page depends on into the new document under a fresh number, rewrites the internal references to point at the new numbers, then rebuilds the cross-reference table so a reader can jump to any object without scanning the whole file.
Get one reference wrong and you get a file that opens with blank pages, or opens in one reader and shows corruption in another. That is why this tool ships a real library rather than a clever trick — unlike turning photos into a PDF, where the image can simply be carried inside the file unchanged.
What does not survive, and why
| Thing | After a merge | Why |
|---|---|---|
| Pages, order, page size | Kept | That is the operation |
| Text and images | Kept, still selectable | Content streams and fonts are copied |
| Links within the document | Kept | Annotations whose targets are rewritten |
| Bookmarks / outline | Lost | A separate tree that points at page objects; needs rebuilding, not copying |
| Form fields | Lost or flattened | Fields live in their own object graph with a document-level registry |
| Comments, highlights | Usually lost | Annotation subtypes tied to per-document registries |
| Digital signature | Invalid | Signature covers exact bytes; any edit breaks it by design |
| Document metadata | Reset | Title, author, producer come from the merging application |
The first three rows are what people actually need. The rest is the reason a bookmarked manual or a signed contract should not go through this — or through any other merger.
Two different things called "password protected"
This is the distinction that costs people the most time, because a file manager shows the same padlock for both.
An open password encrypts the content. Without the password the pages cannot be read at all — the bytes are ciphertext. No tool can merge this without the key, and any tool that claims to has either been given the password or is producing a file with the pages quietly missing. A good merger names the file and leaves it out; a bad one just produces a shorter document and says nothing.
An owner password leaves the content readable and asks a viewer to restrict printing, copying or editing. The pages are not encrypted in any meaningful sense, so they merge fine. Whether you are allowed to merge them is a question about the document, not about the software.
File size after merging
It is not the sum of the inputs. It is usually a little larger than the largest input plus the content of the others, minus whatever shared resources can be reused, plus a new table of contents. Two 2 MB files commonly produce something in the 3.5 to 4 MB range.
It is also not smaller. Merging does not deduplicate fonts across documents in any meaningful way, and it does not recompress images. If the result needs to be smaller, that is a separate compression pass, and it is worth knowing that a scanned PDF usually shrinks the most from downsampling its images rather than from anything else.
Ordering and page size
Both are preserved as they were. A merge does not normalise an A4 invoice and a Letter receipt to a common size, because doing so would rescale content that was typeset for a specific page — and a rescale is a destructive edit nobody asked for. If the mixed sizes bother you, the fix is to print each source to a uniform page size first, accepting that the content gets scaled.
Order is whatever order you put the files in, and it is worth setting it deliberately. Sorted by filename is not the same as the order the document should read in, and a merged file with the signature page in the middle is worse than four separate attachments.
When not to merge
When the document will be signed. Merge first, sign after.
When the recipient needs to fill in a form. Form fields do not survive, and a flattened form is no longer fillable.
When navigation matters. A 200-page manual with a bookmark tree is worse as a merged file, because the tree is the only way anyone finds anything in it.
When the parts have different confidentiality. Merging a public price list with a private quotation produces one file that has to be treated as private. Keep them apart if they will be shared with different people.
Merge them
The Merge PDF tool does this in the browser with no upload, keeps each file's original page size, and names any file it cannot read instead of silently dropping it.
Related: Images to PDF to turn photos into something mergeable, and Compress to a File Size when the result has to fit an upload limit.
Written October 2026. Object structure follows the PDF specification (ISO 32000-1); the signature behaviour described is a property of how digital signatures are computed, not a limitation of any particular library.