File & PDF Tools

Merge PDFs

Reorder and combine multiple PDF files into one document.

Merge PDFs
Select multiple PDFs, reorder them, and combine them into one document.
Local browser processing

Merge PDFs

Copy pages from multiple PDFs in list order and save one new document. Processing stays in the current browser tab.

Boundaries

  • Reorder or remove files before processing
  • Page content is not rasterized or downsampled
  • Password-protected PDFs are not supported

Merges two or more PDFs into one document by cloning every page object from each source in the order you list the files. Pages are never rasterized, so text stays vector and images keep their original compression. Fits joining scanned chapters, appending separately exported appendices, or assembling one deliverable from parts.

Each page is cloned, not re-rendered

The merge runs pdf-lib inside the tab: every source is parsed with PDFDocument.load, then copyPages() clones each page dictionary into a new document and deletes /Parent. Inheritable attributes are baked onto the page first, and pdf-lib only treats /Resources, /MediaBox, /CropBox and /Rotate as inheritable, so a Letter page rotated 90° in its own file arrives rotated 90° and keeps 612 × 792 pt while neighbouring A4 pages keep 595.28 × 841.89 pt. Content streams and image XObjects travel as the same compressed bytes: a JPEG stays /DCTDecode and a Flate image is never decompressed and re-deflated.

Why the result is a new file, not a sum of inputs

The merged file is written from scratch as %PDF-1.7 with object streams (/ObjStm) behind a single cross-reference stream, so any incremental-update history, linearisation hints and orphaned objects in the inputs are gone. Each source gets its own object copier: a 200 KB image referenced by two different files is stored twice in the output, while the same image referenced by ten pages of one file is stored once. Page-level data survives, document-level data does not — the /Title and /Author of the sources are dropped, /Producer becomes pdf-lib, and the creation date is the moment of merging.

Order rules and what gets left behind

Global order is exactly the file-list order: each file contributes all of its pages, so page 1 of the second file lands right after the last page of the first. Only page dictionaries and the objects they reference are copied, which leaves catalog-level structures behind — outlines, AcroForm fields and named destinations are not merged in, and a link annotation whose /Dest points at another page of its own file is copied as an orphan target instead of being remapped to a new page number. The download is always named merged.pdf, and the merge button stays disabled until at least two files are listed.

Worked example

Merging an A4 report with a rotated Letter cover

Input
report.pdf — 2 pages, 595.28 × 841.89 pt; cover.pdf — 1 page, 612 × 792 pt with /Rotate 90, listed second
Output
merged.pdf — 3 pages: 595.28 × 841.89, 595.28 × 841.89, 612 × 792 keeping /Rotate 90; no /Title, /Producer = pdf-lib

Reproduced with pdf-lib 1.17.1 using the same copyPages() call the tool makes: three page dictionaries are copied and no document info dictionary is carried over, so the third page keeps its landscape orientation and the merged file opens with no title in the viewer tab.

Limits and pitfalls

  • Each file must be 100 MB or smaller and the whole selection 250 MB or less; both checks run before parsing, so an oversized batch fails without writing anything.
  • Encrypted PDFs and files with an open password fail at load time — decrypt or re-export an unprotected copy before merging.
  • Document metadata, outlines and AcroForm fields are not merged with the pages, so bookmarks have to be rebuilt against the new page numbers.
  • The download is always merged.pdf, so repeated merges pile up as merged (1).pdf, merged (2).pdf in the same folder.
  • Only files ending in .pdf or carrying the application/pdf type are accepted; dropping anything else clears the current selection with an error.

Related tools

When it goes wrong

I picked a second PDF and the first one disappeared — Merge PDFs is still greyed out.

CauseThe dropzone hands over whatever the file picker or the drop returned, and the tool replaces the entire list with that result instead of appending to it, so the second pick is a new batch of one. The button stays disabled while files.length < 2.

FixSelect both files in a single pick (Ctrl/Cmd-click) or drag them together before releasing, then set their order with the up and down arrows on the file rows. Dragging one more file onto the box later restarts the batch.

One wrong file in the batch made the four PDFs I had queued vanish, and the red line just says INVALID_PDF.

CauseThe extension and MIME check runs over every file before anything is parsed, and the error path wipes the whole selection. The code it throws has no mapping in the error table, so the raw token is printed instead of a readable sentence.

FixTake the non-PDF out of the selection or the drag before dropping, re-add the batch in one go, and prefer files ending in .pdf — a browser reporting an empty MIME type for a .pdf still passes the check.

Chapter 2 needed to start in the middle of chapter 1, but the output is chapter 1 end to end and only then chapter 2.

CauseMerge mode never reads a page expression: it copies the full page index list of each source, file after file, so the smallest unit you can place is a whole document. Order is the order of the file rows, nothing else.

FixSplit chapter 1 at the break point first, then list the three parts in the wanted order. If the merge already happened, repair it with Reorder pages, which takes a complete sequence such as 1,2,3,12,4,5.

The file opens in my reader without asking for a password, yet this page calls it password-protected.

CauseThe load call rejects any document that carries an /Encrypt dictionary, before a single page is read. A permissions-only lock — empty user password, owner password set to block editing or printing — trips exactly the same branch as a file that demands a password to open.

FixExport an unrestricted copy from the app that produced it, or run qpdf --decrypt in.pdf out.pdf and merge the resulting file, which no longer contains the dictionary.

My sidebar bookmarks are gone, and the "see page 12" cross-references in the body do nothing when clicked.

CauseOnly page dictionaries and the objects they reference are cloned. /Outlines and named destinations live in the catalog and are left behind, while a link annotation inside a page keeps its original /Dest array instead of being remapped, so it aims at a page number that no longer exists. External http links survive, because their URI action is stored on the annotation itself.

FixRebuild the outline after merging from the new chapter start pages, and re-create internal links against the merged page numbers. If in-document navigation has to stay exact, keep the parts split rather than merging them.

One concrete scenario

Six scanned chapters becoming one 96-page manual

A manual is coming out of six chapter exports of 12, 8, 20, 16, 24 and 16 pages. All six selected at once give 96 pages in the output, and chapter 4 lands on page 41, because 12 + 8 + 20 pages are queued ahead of it. At roughly 38 MB per scan the batch totals 228 MB: every file is under the 100 MB per-file ceiling and the batch is under the 250 MB total. A seventh chapter of the same size would take the batch to 266 MB and be refused at pick time, although no single file changed. If you must merge in two passes, remember the intermediate is itself a file: two chapters are about 76 MB and can be merged again, three already pass 100 MB. Page numbers and bookmarks do not travel, so add them after the merge.

Frequently Asked Questions

Does merging reduce quality?
No. Merging copies page objects into a new document — text stays vector, images keep original resolution, nothing is rasterized. Mixed-source PDFs keep each page’s own quality.
Can I merge password-protected PDFs?
Files with an open password are not supported; permission-password files are partially limited. Decrypt or re-export an unprotected copy from the source system first.
Do bookmarks and outlines survive merging?
Page content survives fully, but original outlines reference the source structure and are typically dropped — rebuilding bookmarks by new page numbers is more reliable. Internal links targeting moved or removed pages may break.

Content reviewed: