← All posts

Your bookmarks vanished when you merged the PDFs

You had eight chapter files, each with a tidy outline down the side. You merged them into one document, opened the result, and the sidebar is empty. Three hundred pages, and the only way to reach chapter five is to scroll to it.

Or the other version: the bookmarks are still listed, and every one of them lands you on page 1. Which is arguably worse, because it looks like the file is broken.

Neither is damage. Both follow from the same thing about how PDFs store an outline, and once you know it you can tell in advance which merges will keep your bookmarks and which will not.

Why merging drops the outline

Bookmarks are not attached to pages. They live in one tree hanging off the document's catalogue — the object that represents the file as a whole — and each entry holds a title plus a destination: a reference to a page object, and how to position it when you get there.

That means there are two quite different ways to merge, and they look identical from the outside.

The cheap merge makes a new empty document, copies the pages in one by one, and saves. Pages carry their own content, so the text and the images arrive intact. But the catalogue is a brand new one, and nothing put an outline in it. Your bookmarks were not corrupted or stripped — they were simply never copied. This is what most quick merge tools do, and what our own Organize PDF pages and extract tools do too, which is why they hand back a file with no outline as well.

The careful merge copies the outline trees across as well, and rewrites every destination so it points at the page's new object in the new file. That is real work — hundreds of destinations remapped, per source file — and it is the part cheap mergers skip.

Then there is the third case, the one where the bookmarks survive but go nowhere. An entry does not have to name a page directly. It can point at a named destination: a label like chapter1 that is looked up in the document's own table of names. Copy the outline without copying that table and every entry resolves to nothing, so the reader drops you at page 1. And if two of your source files both defined chapter1, one definition wins and every bookmark of that name goes to the same place. That is the mechanism behind "all my bookmarks jump to the front".

Check they have actually gone

Before you rebuild anything, rule out the false alarm. A PDF can ask a reader to open with the bookmark panel showing, and if it does not ask, most readers open with the panel closed. The outline can be perfectly intact and invisible. Open the sidebar by hand — in Acrobat, View, then Show/Hide, Navigation Panes, Bookmarks — and look.

If entries are listed but all misbehave, that is the named-destination failure above and the outline genuinely needs rebuilding. If the panel is empty, it was the cheap merge.

Save the outline before you merge

If you still have the source files, spend two minutes on insurance. pdftk will dump an outline to plain text:

pdftk chapter1.pdf dump_data output chapter1.txt

You get BookmarkTitle, BookmarkLevel and BookmarkPageNumber lines — titles, nesting and page numbers, in a file you can read. pdftk merged.pdf update_info bookmarks.txt output final.pdf puts them back, once you have added each file's page offset to its numbers. It is arithmetic, and it is also the only route that restores your exact titles and their hierarchy. mutool show file.pdf outline prints the same information if you have mupdf-tools instead.

We have no tool that exports an outline as text, so if the nesting matters, do this before you merge rather than after.

Merging so the outlines survive

Our Merge PDF does the careful kind: with both bookmark switches left on and the page range left at "all", each source's outline is carried across and its destinations remapped. Rename the sources before you add them, because each one contributes an entry named after itself and a filename that means nothing to a reader makes a bookmark that means nothing either. Which other tools do it, and the one setting that quietly costs you the outline in almost all of them, is written up tool by tool separately.

What it will not do is nest each source's outline underneath the name of its file: the per-file entries and the sources' own entries end up side by side at one level, for reasons to do with how the tree is grafted. If you need that hierarchy exactly, the pdftk route above is the one.

Rebuilding an outline that is already gone

If the merged file is all you have left, build a new outline from what is on the pages with Create PDF bookmarks.

  1. Check there is text to work with. Everything here reads the text layer. Our PDF inspector tells you whether each page has one, in the browser, without uploading the file. A scanned bundle has none — and on this deployment our OCR tool reports which pages need a text layer rather than adding one, so scans need OCR elsewhere first.
  2. Try headings. A PDF records no such thing as a heading, so what is measured is type size: the size most of each line is set in, compared with the size most of the document is set in. Run it once and read the note, which says something like "the body text of this document is set in 10.5pt".
  3. Set the heading size if the guess was off, a point below your real headings, and run again.
  4. Or match a pattern when the titles are predictable rather than large — Chapter \d+, Schedule \d+, Exhibit [A-Z]. Whatever matches becomes the bookmark's name.
  5. Or bookmark every page, which is unglamorous and never fails. It uses the document's own page labels, so a report with roman-numbered front matter comes out i, ii, iii, then 1, 2, 3.

What this will not do

The outline it builds is flat. One level, no nesting, no chapter with sections underneath. Type size alone is not a reliable guide to heading level on real documents — a pull quote is often larger than a section title — so it does not guess. Hierarchy comes back only from your source files or from pdftk update_info.

Bookmarks land at the top of the page, fitted to the width. They do not scroll to a heading that sits two thirds of the way down.

A single-size document has no headings to find. It says so rather than inventing an outline. Use a pattern or bookmark every page instead.

It does not read your contents page. The lines on a contents page are body text like any other.

There are ceilings, too: five hundred bookmarks per run, twenty pattern matches per page, titles cut at 120 characters. Hitting five hundred nearly always means the pattern or the heading size is catching body text.

What else the merge took with it

Outlines are the loss you notice. Merging also breaks digital signatures on the sources, since a signature covers the bytes of the file it was applied to and this is a new file. Cross-document links and named destinations do not survive a cheap merge either. Form fields do survive ours, as long as the page range stays at "all".

Do the structural work in the right order and you only pay once: fix the page order with Organize PDF pages first, merge second, bookmark last — because every rebuild wipes the outline you just made. If your sources are the fronts and backs of a single-sided scan, interleave them before any of that; that job has its own answer.

And once a document has a good outline, it is worth more than navigation. Split PDF by bookmarks uses it as a cutting plan, giving you one file per entry named after that entry — which is how you get Schedule 2 - Charges.pdf instead of report-4.pdf, and the fastest way to break a bundle back into its chapters. The outline you rebuild today is the thing that takes the merge apart again next month.

Tools this post uses: