PDF merge & split

The three operations

Almost everything people need to do to a PDF that does not involve editing its content is one of three things.

• Merge. Several files become one, in the order you set. Useful for assembling a submission from separately scanned parts, or putting an appendix behind a report.
• Extract. Keep only the pages you name. Useful for sending one section of a long document without handing over the whole thing.
• Remove. Delete the pages you name and keep everything else. Useful for dropping a blank scan, a cover sheet, or a page you would rather not circulate.

Extract and remove are opposites of the same selection, which is why they share the page-range box. If it is easier to describe the pages you want to lose than the pages you want to keep, use remove.

Order matters when merging

The merged file follows the order shown in the list, not the order the files were selected in — file pickers sort alphabetically, which puts “page10” before “page2” and produces a scrambled document. Use the arrows to arrange the list before merging, and check the first and last file are where you expect.

What survives a merge, measured

Pages are copied whole, so text stays selectable, images keep their original resolution, and nothing is re-compressed. Vector content stays vector. Document-level features are a different story, and the usual advice about them is vague enough to be useless, so we measured it.

The fixture is a PDF carrying one of everything: two bookmarks, an external link, an internal link to page two, a sticky-note annotation, a two-field form, a file attachment, title and author metadata, a page rotated 90°, and A4 and Letter pages in the same document. It went through exactly what this tool does — create a new document, copy the pages across, save — and the output was read back and counted. Merging and extracting gave identical results.

Why the losses happen

A PDF is a tree, and pages are only one branch of it. Bookmarks, form definitions, attachments and metadata hang off the document catalogue — a different branch entirely. Copying pages into a new document brings the page branch and everything it points down to, which is why anything living on a page (its content, its annotations, its rotation) comes along, and anything living above the pages does not.

The two “present but broken” rows are the ones worth knowing about, because nothing on screen tells you they happened.

Form fields. The little boxes stay visible on the page, because the widget that draws them is a page annotation. The form definition that made them fillable is not, so it is gone: in the measurement, a document with two fields came out with zero. The result looks like a form and behaves like a picture of one.

Internal links. A link to another page points at that page by reference. After copying, the reference names an object that no longer exists in the new file, so the link stays clickable and goes nowhere. This happens even when the target page was kept — it is not limited to pages you removed.

Title and author are in the table as preserved, but only because this tool puts them back deliberately. Copying pages does not carry them either, and the default result is a file whose title is blank — which is what the recipient sees in their file list and in the reader's tab. On a merge, the first document's title and author are used; there is no correct way to merge two sets of them, and treating the output as a continuation of the first file matches what people expect from it.

Dates are deliberately not carried over. The creation date of the output is the moment you processed it, not the moment the original was written, because a file with different contents claiming the original's creation date would be the more misleading of the two options.

What to check before you send it

None of this matters for the common case — scans, reports, invoices, anything you are assembling to be read. It matters for three kinds of document, and the check takes a few seconds each.

If the original was signed, the signature is invalid afterwards, and correctly so: a signature exists to prove nothing changed since it was applied, and you just changed it. There is no way around this, and a tool that claimed otherwise would be broken. Merge before signing, never after.

If the original was a fillable form, flatten it in your PDF reader first (printing to PDF is the usual way), then merge. Flattening burns the current values into the page content, where they are safe.

If the original had a table of contents you actually navigate by, expect to rebuild the bookmarks in a full PDF editor afterwards. The printed contents page survives; the clickable outline does not.

Why local processing matters more here than elsewhere

PDFs are what people use for the documents they care most about: contracts, tax returns, medical letters, identity documents, unreleased financial statements. The standard way free PDF tools work is to upload that file to a server, process it, and let you download the result — which means a copy existed on infrastructure you cannot inspect, governed by a retention policy you did not read.

Browsers have been able to read and write binary formats in memory for years. Doing it locally is not a compromise for the sake of privacy; it is faster too, because there is nothing to upload and nothing to wait behind.

If you handle documents under a confidentiality obligation, this distinction is not theoretical. Uploading a client's contract to an unknown processor can itself be the breach, regardless of what happens to the file afterwards.