Does merging PDFs reduce quality?

No. Nothing is decoded or re-encoded — image and content streams are copied byte for byte. The merged pages are bit-identical to the originals.

Why did my bookmarks disappear after merging?

Because the outline tree points at page objects that were renumbered, and rebasing it is a separate step from copying pages. A merge that skips it either drops the outline or leaves it pointing at the wrong pages.

Can I merge a password-protected PDF?

Only by supplying the password. Encrypted objects are keyed partly on their own object number, so they cannot be renumbered while encrypted. Unlock, merge, then protect the result again if it needs to stay locked.

Why is merging so much faster than compressing?

Because merging is bookkeeping and compressing is image processing. A merge rewrites object numbers and references; a compression pass decodes, resamples and re-encodes every image on every page.

how does merging pdfs work

How Merging Two PDFs Actually Works

Both files have an object numbered 1. That single collision is the whole reason merging is more than concatenation, and it explains everything that does and does not survive the operation.

Why you cannot just append one file to the other

A PDF is a set of numbered objects and an index of where each one starts. Both of your files number their objects from 1. Both have a catalogue, a page tree, a font dictionary called F1. Concatenate the bytes and you get two competing indexes describing two competing object 1s, and a reader that opens it will see whichever it finds last — which is to say, the second document only.

So the merge has to rewrite. Every object from the second file is copied into the first with a new number, and every reference inside those objects is rewritten to point at the new numbers. A page that said "my contents are in object 12" becomes a page that says "my contents are in object 847".

Then the two page trees are spliced into one, a fresh cross-reference table is built with correct byte offsets for everything, and a new trailer is written pointing at the surviving catalogue.

1. Parse both: Read the object graphs and the page trees. Nothing is rendered.
2. Renumber and copy: Every object from file B gets a fresh ID, and every reference to it is rewritten.
3. Splice the page trees: Build one tree in the order you asked for. Pages themselves are untouched.
4. Rebuild the index: New byte offsets for every object, new trailer, new file.

Why merging never costs quality

Nothing is decoded. Image streams are copied across byte for byte, still in whatever encoding they arrived in. Content streams are copied unchanged. Fonts are copied unchanged.

That is the whole reason a merge is lossless and fast. A 500-page merge is a bookkeeping exercise over a few hundred thousand object references, and a modern machine does it in a second or two. Compare that with compression, which must decode and re-encode every image in the file.

It also means a merged file is exactly as good and exactly as bad as its inputs. Merging a blurry scan with a crisp export gives you a document that is blurry on one half. Nothing normalises.

What has to be repaired along the way

Renumbering objects is mechanical. Everything that referred to those objects by name rather than number is not.

Bookmarks and outlines: The outline tree points at page objects. It has to be rebuilt and rebased, or the second document's bookmarks land on the first document's pages — or vanish.
Internal links: Cross-reference links and table-of-contents jumps are destinations pointing at page objects, and need the same remapping as bookmarks.
Form fields: Fields are addressed by name. Merge two copies of the same form and you get two fields called `name`, which most readers treat as one field that fills both. Flattening first avoids it.
Duplicate resources: Both files embed Helvetica as a subset under different internal names. Nothing can prove the subsets are interchangeable, so both ship — which is why a merged file is sometimes larger than the sum of its parts.

Encryption has to come off first

In an encrypted PDF, streams and strings are encrypted individually, with a per-object key derived from the file's encryption key combined with that object's number and generation. The object number is part of the key.

Which means renumbering an encrypted object silently invalidates it. To merge, the tool must decrypt with the file key first, copy the plaintext objects, renumber them, and encrypt the result under a new key if the output is to be protected. That is why a merge tool asks for the password rather than working around it, and why the output is unencrypted unless you protect it again afterwards.

Splitting is the same operation in reverse

Splitting builds a new file containing only the pages you asked for, plus every object those pages reach — their content streams, their fonts, their images, and nothing else. It is a graph traversal from a set of roots.

This is why splitting a 100-page document in half rarely gives two files at half the size. If a font or a logo is used on pages throughout, both halves need their own copy of it. Shared resources are duplicated, not divided.