← All posts

Which merge keeps your PDF bookmarks?

You have eight files. Each one opens with a proper list down the left — chapters, schedules, exhibits — and the entire point of merging them is to end up with one document that still has that list.

Three different tools offer a button marked Merge. Not one of their pages says a word about bookmarks, and the first one you tried handed back three hundred pages with an empty sidebar.

Rebuilding an outline by hand is an afternoon, so it is worth two minutes to know what decides it. Two things do, and only one of them is which tool you picked.

What a merger has to do, and why half of them skip it

Bookmarks are not marks on pages, and copying pages into a new document therefore brings neither the outline nor the identity of the pages its entries point at, which is why the panel comes back empty. That mechanism, including the version where every entry lands on page 1, is written up separately.

What is worth adding here is why it is skipped so often. An outline is a tree, and a tree is not a list you can concatenate. Each node points at its parent, at the sibling before it and the sibling after it, and carries a count of how many descendants it has. Grafting file two's outline onto file one's means relinking that chain at the join, reparenting every top-level entry, recomputing the counts up the tree, and then rewriting every destination in it to name the page's new object. Follow those parent pointers naively and you walk straight back up into the source document's catalogue and start dragging the whole file across.

So there is no cheap partial version. A merger either does all of that or does none of it, and doing none of it still produces a file that opens and looks right.

The setting that costs you the outline in almost every tool

Here is the part nobody mentions. Whether the outline survives often has nothing to do with the tool and everything to do with whether you asked for whole files or for a page range out of each one.

The reason is the destination again. An entry names a page. Take a subset of the pages and some entries now name pages that are not in the output, and the tool has to decide what to do about them. There is no good answer available. What should become of "Chapter 4" when you kept only the first page of chapter 4? Of a parent entry whose children are all gone? Of the count on the node above it?

Nobody prunes. Everybody picks one of two blunt options:

Which means the honest instruction is: if the outline matters, merge whole files. Do your cutting before or after, not during.

Which routes keep them

Worth being clear about what you are protecting. An outline is not only navigation: it is also the cutting plan that lets Split PDF by bookmarks take the bundle back apart into one named file per chapter next month, which is the thing people wish they had when they merged.

Merging so the panel survives

  1. Rename the files first. Each one contributes a bookmark named after itself with the extension removed, so 03 Witness statement - A Sharma.pdf reads well in the panel and scan_0003.pdf does not. Number them 01, 02 while you are there, or your file picker hands over 10 before 2.
  2. Get the order right in the list, because fixing it afterwards with Organize PDF pages rebuilds the document and throws away the outline the merge just preserved.
  3. Leave the page range at "all", and leave both bookmark switches on.
  4. Open the result at the joins. A wrong order shows itself there and nowhere else.

Checking it in a minute

A panel with entries in it is not the same as a panel that works. Three clicks tell you:

  1. The first entry belonging to your second source. This is where remapping fails first. If it works, the tree was rewritten rather than copied.
  2. Something in the middle of the last source. Catches an offset that only shows up once the page count is large.
  3. Anything with children. Confirms the nesting survived the graft.

The per-file entries are the ones that cannot fail, for a boring reason: they are created after the merge and point directly at a page object in the finished file, fitted to the width. There is no name lookup involved, so there is nothing to dangle.

If you want the count rather than the clicks, pdftk merged.pdf dump_data_utf8 lists every entry with its level and page number; compare that against the same command run on the sources. Our PDF inspector does not read outlines — worth saying plainly — but it reads the page count in your browser without uploading anything, which is the other number you want to check.

Whether the sidebar opens at all is decided by your first file

Whether the panel opens by itself is a request stored on the document rather than on any page, and a merged document is new, so it inherits that request from the first source that made one. Put a file that never asked for it at the top of your list and the merged report opens with the panel shut, outline intact, looking exactly like the failed merge you were trying to avoid.

Same mechanism for page numbering, which does survive: each source's page labels — the i, ii, iii front matter and the restarts — are carried across and shifted to their new positions. That is usually what you want and occasionally a mess, because a document where one source is labelled and the others are not ends up numbered plainly for one stretch and in roman numerals for another. Check the page box in your reader if the numbering matters.

What this will not do

The per-file entries do not become parents. The sources' own entries are appended to the root of the tree as the merge runs, and the file entries are inserted in front of them afterwards, so they end up siblings at the same level rather than a hierarchy. If you need each file's chapters tucked underneath its name, that is Acrobat's Combine, or pdftk update_info and some arithmetic.

Every other page tool drops the outline. Organize, extract, delete and split all copy pages into a fresh document, and the outline is not on the pages. That is the order-of-operations trap: do the page work first, merge second.

Fifty files a run, mixed page sizes stay mixed, an encrypted file is refused until you unlock it with the password you already have, and no digital signature on any source survives the merge.

The sources that never had an outline

Merging cannot preserve what was not there. Three of your eight files came out of a scanner or an export that never wrote one, and the merged panel will be lopsided in exactly those places. The per-file bookmark covers them at chapter granularity, which is often enough.

If it is not, build the missing outlines with Create PDF bookmarks before you merge, one file at a time. It works from the document's headings or from a pattern you type, and a scan defeats it; what it finds and what it will not is worth reading before you count on it.

Before, not after, is the whole point: run it on the merged file and it replaces the entire outline, including the five good ones you just spent all this trouble protecting.

Tools this post uses: