Blog

What merging PDFs quietly throws away

We measured what survives a PDF merge: pages and text do, form fields, bookmarks, tags and signatures do not. Here is the table and the reason.

By Harish6 min read

Merging PDFs keeps the pages and the text and drops almost everything else. Form fields stop being fillable, bookmarks disappear, accessibility tags are gone, and any digital signature is invalidated the moment the file is rewritten. If you are assembling an exhibit bundle, a board pack or a closing binder out of finished pages, that is fine. If any part of the bundle still has to be filled in or has already been signed, merge last, or do not merge at all.

This post is the honest table. We measured it against our own merger rather than describing it from memory.

What we measured

We built a two page PDF carrying the structures that matter in professional documents: an interactive text field named counterparty.name, a link annotation pointing at an external URL, a bookmark pointing at page two, and a document title and author. Then we merged it with a copy of itself and inspected what came out. We ran the same test again with a tagged document, which is the structure that makes a PDF accessible.

What the file had Survives the merge?
Pages, in order Yes
Text and images on the page Yes
Link annotations Yes
The box a form field draws Yes, it is still drawn
The form field itself No. Nothing can fill it
Bookmarks and the outline tree No
Document Title and Author No, replaced by the merging tool’s own
Accessibility tags and the MarkInfo flag No
A digital signature No, and this one is by design

The fourth and fifth rows together are the trap. The text box is still visibly on the page, because the thing that draws it is attached to the page. The field is gone, because the thing that makes it a field is attached to the document. The merged bundle looks fillable and is not.

Why it happens

A PDF is not a stack of pages. It is a small database with a root object called the catalog, and the pages hang off it. So do a lot of other things.

Merging works by copying pages from each source document into a brand new document. Anything attached to a page travels with it. Anything attached to the old catalog does not, because the old catalog is not what you are copying.

That single sentence explains every row in the table.

  • Form fields live in an AcroForm dictionary in the catalog. The visible box is a widget annotation on the page and it comes across. The entry in the form register does not, so no viewer has anything to fill.
  • Bookmarks live in an Outlines tree in the catalog, and each entry points at a page by reference. Copy the pages into a new document and every one of those references points at nothing.
  • Accessibility tags live in a StructTreeRoot in the catalog. It is a parallel tree describing which marks on the page are a heading, which are a table row, and in what order a screen reader should read them. It is attached to the catalog, so it goes.
  • Document metadata is in the trailer, not on any page, so the new document starts with whatever the merging tool writes.

None of this is a bug in one tool. It is the shape of the file format. A merger that preserved all of it would have to rebuild the form register, rewrite every outline destination, and stitch two tag trees into one valid tree. Acrobat does some of this. Most free tools, ours included, do not, and a tool that quietly did it badly would be worse than one that does not try.

The signature row is different

The other rows are a limitation. The signature row is the point.

A digital signature covers a byte range of the file and stores a hash of it. A viewer validates the signature by hashing those bytes again and comparing. That is the entire mechanism, and it is what makes a signature worth anything: the signature says “these exact bytes were what I signed.”

Merging rewrites the file. Different objects, different offsets, different bytes. The hash no longer matches, so the viewer reports the signature as invalid. There is no clever merger that avoids this, because a tool that could change the document and keep the signature valid would be a tool that defeats digital signatures.

The only way to add pages to a signed PDF without breaking the signature is an incremental update, which appends to the file rather than rewriting it, and even then the viewer will report that the document was changed after signing. For practical purposes: merge first, sign last.

The same applies to signature packets. Assemble the full document, then send it for signature. Do not collect five signed PDFs and merge them into one, because the result is a document where all five signatures report as broken and a recipient cannot tell your assembly from a forgery.

What this means for the usual jobs

Exhibit bundles and hearing bundles. Safe to merge. The exhibits are finished pages and nobody is filling them in. Add page numbers after merging, not before, so the numbering runs across the bundle. Expect to rebuild bookmarks in whatever tool your court or chambers wants them in.

Closing binders and board packs. Safe to merge, with the same bookmark caveat. If the pack is going to be published rather than circulated, see the accessibility note below.

Anything with a form. Do not merge. Fill the form, then flatten it, then merge. Most PDF tools have a flatten step that turns the filled field into ordinary drawn text. Once it is flat, it is just marks on a page and it survives anything.

Anything already signed. Do not merge. Rework the order so the signature is the last thing that happens.

Anything that gets published on a website. Merging strips the tag tree, so a merged PDF is untagged, and an untagged PDF is not accessible. If the bundle is going on a public body’s website or a university’s site, the merge has just created remediation work. Tag after merging, never before.

The small print on our merger

Ours copies pages into a new document and writes its own Title and Producer. It does not attempt to preserve forms, outlines or tags, and this post is the reason we would rather say so than let you find out from a bundle that nobody could fill in.

It runs entirely in your browser, which matters more than usual for this job: an exhibit bundle is usually the most confidential thing a firm produces in a given week, and a browser-side merge means the files are never sent anywhere.

How to check a file yourself

You do not need to take our word for the table. Open the merged file and try four things:

  1. Click where a form field used to be. If nothing gets a cursor, the field is gone.
  2. Open the bookmarks or outline panel. If it is empty, the outline is gone.
  3. Open document properties and look at Title and Author. If they are the merging tool’s own, the metadata was replaced.
  4. If the file was signed, the viewer will tell you on open. Acrobat and most browser viewers show a banner.

For the tag tree you need a checker rather than a viewer, since nothing in the normal interface shows it. That is a topic of its own.

Further reading