PDF Merge

How does it work?

Behind it sits pdf-lib, loaded via CDN. It opens each PDF, copies the pages into a fresh document and assembles the result.

None of this leaves the browser, so your files never end up on a server. With large PDFs, expect a few seconds of processing.

Merging works with unprotected PDFs. If a file is encrypted, unlock it before you start.

Why merge PDFs

Joining several PDF files into a single document has been one of the most frequent office tasks for the last two decades. You hit it whenever an expense report has to travel alongside the scanned receipts, when a project deliverable bundles a proposal with a contract and an annex, when a researcher folds dozens of separate papers into one reading binder, or when a lawyer prepares an evidence dossier that has to be filed as a single continuous file. The motivation rarely changes. Instead of mailing someone a folder full of loose attachments, you hand over a coherent package that opens in one viewer tab, paginates correctly, and can be archived, signed or printed as a single unit.

The scenarios reach well past bureaucracy. Self-published authors merge the cover, front matter, chapters and back matter into the final manuscript before it goes to Kindle Direct Publishing or a print-on-demand service. Designers concatenate mood boards, wireframes and final mockups into a portfolio. Engineers stitch CAD drawings, datasheets and certification documents into a build package, and teachers pull activity sheets from a handful of different sources into one printable booklet. Tax season produces its own share of merges too, when filers attach invoices, statements and form copies to a return before sending it off.

Contract management turns out to be a surprisingly common business case. A signed contract tends to grow over its lifetime through addenda, amendments and side letters. Keep each amendment as a separate file and auditing becomes painful, since reviewers are left reconstructing the chronological order from filenames. Merge them into a single PDF, with the original contract first and each addendum appended in date order, and the legal team gets one source of truth that mirrors how a paper contract folder would have been organised on a shelf.

How a PDF is built: objects, xref table and trailer

The PDF format, standardised as ISO 32000, is not a single linear stream of text and images. Internally a PDF behaves more like a small object database. The file opens with a one-line header such as %PDF-1.7 that names the specification version. Below the header sits the body, made of numbered objects. Each page, each font, each embedded image, each annotation and each form field is a discrete object carrying a unique pair of identifiers: an object number and a generation number.

At the end of the file sits the cross-reference table, almost always called the xref table. The xref is basically an index recording the byte offset of every object in the file. A viewer opening a PDF does not parse the whole document. It jumps straight to the xref, builds an in-memory map of where each object lives, and then loads only the objects the current page actually needs. That random-access design is the reason a PDF can open the last page of a thousand-page report at once, without touching any of the pages before it.

After the xref comes the trailer, a small dictionary pointing to two key objects. One is the document catalogue, the root of the page tree, metadata, bookmarks and interactive features. The other is the Info dictionary, which holds the title, author, creation date and producer. The trailer also stores the byte offset of the xref itself, so a reader can work the file backwards from its tail. Once you picture that architecture, it becomes clear why merging PDFs is more than concatenating bytes. The merging tool has to collect the objects from each input file, renumber them so the IDs do not collide, rebuild a single page tree, recompute every byte offset, and emit a brand-new xref and trailer for the resulting file.

Privacy: local processing versus server upload

Most popular online PDF tools work by uploading your files to a remote server, running the merge there and sending the result back. ILovePDF, Smallpdf and Adobe Acrobat online services all follow that pattern. Their privacy policies usually promise to delete the uploaded files within a few hours. That is reasonable enough for casual documents, but it raises real concerns the moment the PDFs hold personal identifiers, medical records, payroll data, signed contracts or trade secrets.

This tool goes the other way. The merge runs entirely inside your browser, and the files you select never cross the network. Modern browsers expose enough cryptographic and binary-handling APIs (ArrayBuffer, Blob, FileReader, WebAssembly) for JavaScript libraries to parse and rewrite a PDF locally, often at a speed close to a native desktop tool. What that buys you in practice: you can merge confidential documents on public Wi-Fi, behind a corporate firewall or on an airplane with no internet at all, and no third party ever sees a single page.

Server-side mergers do have their advantages. They can run OCR on scanned pages, compress automatically, and handle very large files that blow past the browser memory budget. They also spare the user's device, which matters on a cheap laptop or a phone. What you give up is privacy, plus the usual free-tier ceilings, since most online services cap the number of merges per day or per session while a local tool has no quota at all.

pdf-lib: the open-source engine behind in-browser PDF

The library doing the heavy lifting here is pdf-lib, a MIT-licensed TypeScript project compiled down to plain JavaScript. It runs in any JavaScript environment that supports typed arrays, so browsers, Node.js, Deno and even React Native are all fair game. There are no native bindings. One bundle works everywhere, and you never have to worry about a server-side install breaking the day the host OS gets updated.

In terms of what it can do, pdf-lib lets you create PDFs from scratch, copy pages between documents, insert or remove pages, draw text and vector graphics, embed PNG and JPEG images, and create or fill interactive form fields. For merging the API stays conceptually simple. You create a destination PDFDocument, load the source documents, call copyPages to transfer the pages you want, and serialise the destination to bytes. Under the hood pdf-lib walks each source object graph, deep-clones the objects it needs (fonts, images, content streams) and rewrites every internal reference so the output PDF ends up with a coherent xref table.

Being MIT-licensed and free of telemetry also makes pdf-lib a popular pick in regulated industries that audit every dependency they ship. The same library quietly powers internal tools at banks, hospitals and government agencies that simply cannot push documents to a third-party SaaS.

Advanced cases: reordering, bookmarks and digital signatures

Past a straight concatenation, real-world merges often demand fine control over the page order. Think of a printed booklet: the cover has to come first, the table of contents second, and the chapter PDFs follow in a fixed sequence no matter what order they were dropped into the tool. Other workflows want a separator page inserted between sections, or duplicate front matter removed, or the blank back page of a duplex-printed document skipped.

Bookmarks, which the PDF spec calls the document outline, are another sticking point. Merge two PDFs that each carry their own outline and a naive merger throws both away, leaving the reader staring at an empty navigation panel. A more careful workflow either keeps the original outlines as nested entries or builds a fresh one that lists each source filename as a top-level entry. pdf-lib exposes the catalogue object, so constructing an outline like that is possible, but it takes extra code.

Digital signatures deserve a word of their own. A signed PDF embeds a cryptographic hash of the entire byte stream as it stood at signing time. Any modification, a merge included, invalidates that signature because the hash stops matching. The only fix is to re-sign the merged document with a valid certificate. When the signature is legally required, the safer pattern is to merge first and sign once at the very end.

Limits to be aware of

A handful of PDF types just don't merge cleanly with a browser-only tool:

• Password-protected PDFs won't load in pdf-lib until they have been decrypted, since the library does not implement the AES decryption pipeline.
• Digitally signed PDFs lose their signature once merged, for the reason described above.
• Interactive PDF forms that share field names across input files can end up with duplicated or shadowed fields when both documents define a field under the same identifier.
• Very large PDFs (hundreds of megabytes, or thousands of pages stuffed with high-resolution images) can run the browser out of memory, mobile devices most of all.
• PDFs leaning on uncommon font subsets or non-standard encodings may look fine in the source viewer yet show fallback glyphs after merging, when the embedded font tables turn out to be only partially present.

Best practices after merging

A merged PDF is rarely the last artefact in the chain. Three follow-up steps tend to be worth the trouble. Compression comes first: combining several PDFs often duplicates fonts and images, and a pass that subsets the fonts and recompresses the images can shave 30 to 70 percent off the file size with no visible loss. Next is OCR on any scanned pages, which makes the merged document searchable; a contract bundle that mixes typed amendments with scanned signatures gets a lot more useful once full-text search reaches every page. And for anything headed into long-term storage, the third step is conversion to PDF/A.

PDF/A (ISO 19005) is a profile of PDF built for archiving. It bans anything that depends on external resources (linked fonts, embedded JavaScript, encryption) and insists that every glyph used in the document is fully embedded. The flavour you pick matters. PDF/A-1 is based on PDF 1.4 and is the strictest of the bunch, PDF/A-2 adds transparency and JPEG2000 support, and PDF/A-3 goes further by allowing arbitrary file attachments, handy when you want to embed the source spreadsheet right beside its rendered invoice. Public institutions and regulated industries frequently demand PDF/A-2b or PDF/A-3b for permanent records.

FAQ

Is there a file size limit? The tool sets no hard limit, but the browser keeps every file in RAM for the duration of the merge. A typical laptop handles totals up to a few hundred megabytes without complaint; on a phone, stay well under that.

Are my files uploaded anywhere? No. The merge runs in your browser using pdf-lib. The files never leave your machine, and no copy is ever kept on a server.

Can I reorder pages before merging? The widget merges files in the order they were added. For control at the page level, reorder the files in your file manager before selecting them, or split the larger PDFs into single-page files first.

What happens to a digital signature? The merge breaks it. If the combined document needs a signature, sign it once after merging with a certificate-backed tool.

Can I merge password-protected PDFs? Not directly. Strip the password in a PDF viewer first, then merge the unlocked copy.