Merging PDFs in a Browser Tab

The first tool I built for Toolium was a PDF merger, and I built it because I had spent forty-five minutes on a Monday morning trying to combine a signed lease agreement with three scanned addenda. Every free tool I tried online either added a watermark, made me sign up, queued my upload behind a hundred other anonymous users, or wanted me to install a desktop application I would use for ten seconds and then forget about. The lease was confidential. I did not want it sitting in some unknown server cache. So I wrote my own merger in an afternoon, and the version of it that ended up on Toolium is the same code, just with a friendlier interface and a few months of bug fixes.

If you have ended up here looking for a way to combine PDFs without giving up your files to a stranger, the short version is: open the PDF Merge tool, drag your files in, reorder them, click merge, and you are done. The rest of this post is the long version - what is actually happening under the hood, what survives the merge and what does not, and the specific bugs I ran into building it that you should know about before you trust your important documents to any tool of this kind.

What "merge in the browser" actually means

When you upload a file to a typical online PDF tool, your PDF leaves your computer, travels across the public internet, sits in someone else's RAM (or worse, on disk) while their server runs a pdftk or Ghostscript command on it, and then returns to you as a download. The privacy implications of that flow are pretty obvious: you have to trust that the server discards the file when it is done, that nobody is logging the contents, that the upload itself is not being intercepted, and that the operator is not selling aggregated data about who merges what kinds of documents.

"In the browser" means none of that happens. Your PDF is read by JavaScript running on the same page you are viewing - the same JavaScript that draws the buttons and handles your clicks. The merge operation runs on your CPU. The output is a Blob in browser memory, which gets turned into a download link. The file never crosses a network boundary. If you opened your browser's dev tools and watched the Network tab while you used the tool, you would see analytics requests and the AdSense beacon, but you would not see any request that contains your PDF data, because there is no such request. This is provable, not just a promise.

The library doing the actual work is called pdf-lib. It is a pure-JavaScript PDF manipulation library, originally written by Andrew Dillon, that handles reading and writing PDF files according to the ISO 32000 specification. It has been around for years, has thousands of stars on GitHub, and is used in production by enough companies that the obvious bugs have long since been shaken out. Toolium does not do anything clever on top of it; it just calls pdf-lib's PDFDocument.load to read each input, copyPages to extract the pages, addPage to add them to a new document in the order you specified, and save to produce the output bytes.

The walk-through, with the gotchas

The mechanical steps are simple. Drag your files onto the drop zone (or click to open a file picker). The tool reads each one, extracts its page count, and shows it in the staged list. From there you can reorder by using the up and down arrows next to each file - the final merged PDF follows the order in the list, top to bottom. Click "Merge PDFs," wait one to three seconds depending on file size, and your combined PDF downloads to your default downloads folder.

The gotchas are the part you actually need to know:

Hyperlinks inside the page content survive. A link in the body of one of your source PDFs - one that opens a website when you click it - is preserved in the merged output. This is because pdf-lib copies the annotation objects along with the page content.
Bookmarks do not survive. If your source PDFs had a sidebar outline of headings or section markers, those get dropped during the merge. This is a limitation of pdf-lib's copyPages method, which copies the visual page content but not the document-level outline. If you need bookmarks in the merged output, you have to add them after the fact in Adobe Acrobat or another desktop tool.
Form fields go through unpredictably. Interactive PDF form fields (text inputs, checkboxes, signature placeholders) sometimes survive and sometimes get flattened, depending on how the source PDF was authored. The pdf-lib documentation acknowledges this; in practice I have found that PDFs produced by Adobe tend to keep their fields, while PDFs produced by web-to-PDF converters lose them.
Digital signatures get invalidated. This is by design - a digital signature covers a specific document, and the merged output is a different document. If you merge a signed PDF with another file, the signature in the output will show as "invalid" or "signature was made on a different document." If you need the signed version, do not merge it; keep it as a separate file.
Encrypted PDFs are rejected, not silently merged. Earlier versions of the tool would attempt to merge password-protected PDFs and produce a corrupted output that looked fine until you tried to open it. I now detect encryption up front and tell you the file cannot be merged without the password. (Browser-based decryption with a password is technically possible but adds enough complexity that I have not built it yet.)
File size matters more than page count. The tool can handle individual files up to about 100 MB before browser memory pressure becomes a problem. Page count itself is not really the constraint - what matters is how many embedded images and fonts each file carries. A 5-page PDF full of high-resolution images can be larger and slower to process than a 200-page PDF of text.

Why the merged file is sometimes smaller than the sum of inputs

People occasionally report this as if it is a bug. They merge a 5 MB file with a 3 MB file and get a 7 MB file instead of an 8 MB file, and write in asking whether the tool is silently compressing their content. It is not. What is happening is that pdf-lib's save method writes the output PDF with "object streams" enabled, which is a standard PDF feature that lets the file deduplicate identical objects. If two of your input PDFs both embed the same font, the merged output stores that font once instead of twice. Same with images and metadata. The actual page content is preserved bit-for-bit; only the redundant object encoding gets collapsed.

This is also why, occasionally, the merged file is larger than the sum of inputs - the object stream encoding has overhead, and for PDFs that share no common objects, you can come out slightly worse. The difference is usually under 5% either way.

When not to use a browser-based merger

This is the part most "free PDF merger" articles leave out. The browser approach is genuinely the right call for almost every personal use case I can think of, but there are situations where you should reach for a desktop or server tool instead:

Merging hundreds of files in a batch. The browser is fine for combining ten or twenty PDFs at a time. If you have a folder of 500 invoices to merge into a single archive PDF, write a five-line Python script using pypdf or pdfsam. The browser can technically do it, but the user experience of dragging in 500 files is not what the tool was designed for.
Automated workflows. If you need PDF merging as part of an automated pipeline (a cron job, a server-side document processing step), a browser-based tool is the wrong fit. You want a command-line tool or a library you can call from your own code.
Truly large files. If your input PDFs are over about 100 MB each, browser memory becomes a real constraint. The tab can run out of memory and crash. For very large files, desktop tools like PDFSam Basic (free, open-source, runs locally) or Acrobat (paid, but supports streaming) handle them better.
Need for OCR or text extraction. Merging does not add searchable text to a scanned PDF. If your scans came from a phone camera or older scanner without OCR, the merged output will still be image-only. For OCR, Tesseract on the command line is your friend; the browser version of Tesseract.js exists but is much slower and uses an enormous amount of memory.

What I do not let the tool do, and why

Toolium's PDF Merge intentionally does not have features that I think would create more problems than they solve. It does not let you reorder pages within a file - if you need to do that, split the file first using PDF Split, then arrange the resulting pieces. It does not let you set the merged PDF's metadata (title, author, creation date) because most users would not bother setting these and the ones who care can edit them after with a desktop tool. It does not flatten form fields or print-to-PDF the inputs to get rid of editing affordances; that is a different operation entirely.

This is the design tension behind every Toolium tool: enough options to solve the common case well, not so many that the interface becomes a list of checkboxes you have to read carefully to understand. PDF Merge is, deliberately, a tool that does one thing.

A short troubleshooting list

The most common questions I get about the tool, with the answers in one place:

"It's not merging - the merge button does nothing." Make sure you have at least two files added. The merge action requires at least two inputs; clicking it with one file is a no-op.
"It says my file cannot be read." Almost always means the file is password-protected. Some scanners produce PDFs that look unencrypted but have an empty password set, which pdf-lib correctly rejects. Open the file in Preview or Acrobat, remove the password, save, then try the merge again.
"My merged PDF opens in Acrobat but looks blank in Preview." Rare, but happens with PDFs that use non-standard compression. Usually a "Save As" in Acrobat fixes it. Tell me if you hit this one; I want to track down a deterministic repro case.
"Can I undo the merge?" The merge is non-destructive - your original files are untouched. The output is a new file. You can throw the merged PDF away and start over without losing anything.
"How do I share the merged PDF?" The same way you would share any PDF: email attachment, cloud drive, message attachment. The merged file is just a regular PDF; no Toolium-specific format or watermark.

If you want to read more about how Toolium works in general, the methodology page covers the broader principles - why everything runs in the browser, how I pick which tools to build, and ten specific bugs I have shipped fixes for. If you have a specific question or hit a bug in the tool, email dev@devtoolium.com; I read every message.