Merging two PDFs sounds like concatenating two files. It is not. A PDF is an object graph with an index at the end, so merging means copying objects out of one graph into another, renumbering every reference, and rebuilding the index. Most of the surprises come from what happens to the objects that are not simple page content.
What survives reliably
- Page content. Text, vector graphics and images copy across intact. Nothing is re-rendered, so quality is unchanged.
- Embedded fonts. They come along with the pages that use them.
- Page dimensions and rotation. Each page keeps its own size, which is why an A4 document merged with a US Letter one produces a file whose pages are subtly different widths.
- Images. Copied byte-for-byte, not recompressed.
What often does not
Interactive form fields. A PDF form lives in a document-level structure called the AcroForm, plus per-page widget annotations. If both documents have a field named name, you now have two fields with one name, and viewers will either link them (typing in one fills the other) or drop one. If you are merging filled forms, flatten them first, flattening converts the filled values into ordinary page content, which merges perfectly.
Bookmarks and outlines. These are a document-level tree. Many merge implementations rebuild pages but not the outline, so a 200-page manual with a full table of contents can come out with no navigation at all.
Digital signatures. A cryptographic signature covers a specific byte range of a specific file. Merging changes the bytes, so the signature is mathematically invalidated. This is correct behaviour, not a defect, a signature that survived editing would be worthless.
Internal links. A link that pointed to "page 12 of this document" may now point at the wrong page unless destinations are remapped.
Attachments, JavaScript and embedded media. Frequently dropped.
Why the merged file is bigger than the sum
Merge a 3 MB and a 4 MB file and you can get 12 MB. The usual culprit is fonts and resources being copied twice. If both documents embed the same font, a naive merge stores two full copies rather than recognising they are identical. The same applies to a logo image repeated on every page of both files.
The fix is a compression pass after merging, which deduplicates identical objects. Merge first, compress second, never the other way round.
A merge checklist that avoids rework
- Decide the order before you start. Reordering after the fact means dragging thumbnails around; naming your files
01-cover.pdf,02-body.pdfsorts the problem out at the source. - Flatten any filled forms. This locks in the values and removes the field-name collision problem entirely.
- Check page sizes. Mixing A4 and Letter is fine on screen and annoying in print. If it will be printed, normalise first.
- Merge, then compress. In that order, for the deduplication reason above.
- Open the result and scroll the whole thing. Especially the seams between documents, that is where a missing page or a wrong rotation shows up.
The upload question
Merging is one of the most common reasons people hand documents to an unknown web service, and it is also one of the least justified. The operation is pure object copying: no rendering, no server-side libraries you could not run locally, no computation a laptop struggles with.
NextTool's PDF merger runs the whole thing in the browser tab. The files are read into memory, the new document is assembled, and a download is produced. Nothing is transmitted, which matters when the documents in question are a lease, a medical report or a set of ID scans, exactly the sort of thing people merge most often.
If you only need a handful of pages from each source, split out those pages first. Merging less is always faster than compressing more.