How to Merge PDF Files in the Browser Without Uploading Them

Combining two PDFs into one is one of the most common file operations on the web. People do it every week without thinking about it. The expense report needs the receipts stitched together. The signed contract came back in three parts. The slide deck needs the appendix joined to the end. The pattern is always the same: several PDFs in, one PDF out, in the order the user picks.

What most people do not know is that this entire operation can run locally in a regular browser. No upload, no waiting in a queue, no third-party server holding the file for thirty days before deleting it. The technology that makes this possible has been stable for several years, and the cost of running it client-side instead of server-side is roughly zero for the file sizes people actually merge.

This post explains what merging does at the PDF format level, how a browser can do it without help, what carries over from the source files, the cases where merging is the wrong tool, and how the Merge PDF tool on this site puts the pieces together.

What a PDF looks like before you merge it

A PDF file is a small filesystem in a single binary container. At the root is a catalog. The catalog points to a page tree. The page tree points to each page object. Each page object points to its content streams (text, images, vector paths) and to its resources (fonts, color spaces, embedded files).

This structure is the whole reason merging is cheap. The pages do not need to be re-rendered, recompressed, or even fully understood by the merging library. To combine two PDFs into one, the library copies the page objects from both source documents into a single new page tree, links them under one fresh catalog, and writes the result. The actual pixel data, the embedded fonts, the form fields, and the hyperlinks all come along for the ride because they are reachable from the page objects. The PDF format was designed to be assembled from independent pieces, and merging is the operation it is most ready for.

How a browser does the work

Server-side PDF tools usually use a native library like PDFBox or QPDF. The shift to browser-side merging is the arrival of pdf-lib, a JavaScript library that re-implements the parts of the PDF specification needed for parsing and writing PDFs entirely in JavaScript. It handles the same merge operation that the server-side libraries do, slower in throughput but plenty fast for the file sizes users actually pick.

The path inside a browser-based merger:

1. The user picks PDF files from their device.
2. The library reads each file into memory as a typed array of bytes.
3. For each source PDF, the library parses the byte stream into the in-memory object tree described above.
4. The library creates a fresh empty PDF in memory and starts copying. For each source, it walks the page tree, copies each page object into the destination's page tree, and reroots any references the page object had into the destination's object table.
5. Resources like fonts and images are copied along with the pages. The library handles the namespacing automatically, so two source PDFs that both embed Helvetica end up with one shared Helvetica reference in the output.
6. The library serializes the destination PDF back to a byte stream and offers it for download.

A typical merge of two to five files runs in a few hundred milliseconds. Twenty files totaling 100 megabytes take one to four seconds on a laptop, slower on phones because of memory pressure. The first load downloads a small JavaScript bundle for pdf-lib (around 200 kilobytes minified and gzipped); after that everything runs offline.

What survives the merge

Because merging copies page objects byte for byte, nearly everything that was inside the source PDFs ends up in the output:

• Text remains selectable. The original text streams are preserved exactly. The output is not an image of the page; it is the same page.
• Image quality is identical. Embedded images carry over at their original resolution and encoding. There is no recompression step.
• Vector content stays sharp. Lines, shapes, and font glyphs render at full quality at any zoom level.
• Fonts are preserved. Embedded fonts are copied, and the library deduplicates them where possible (the same font referenced by two sources only needs to be embedded once in the output).
• Hyperlinks and bookmarks survive. External links to URLs work in the output. Internal cross-page links work if both ends of the link are in the merged set.
• Form fields survive. Filled-in or empty form fields carry over. They remain interactive in the output.
• Page sizes are preserved. A merge of a US Letter PDF and an A4 PDF produces a single PDF with mixed page sizes. The library does not rescale or reformat anything.

A few things do not survive:

• Digital signatures. A signature is computed over the exact bytes of the source PDF as a whole. The moment those bytes change, the signature is invalid. The signature must be reapplied to the merged document if signing is the goal.
• Some interactive multimedia. Embedded video and audio annotations, JavaScript actions, and certain dynamic XFA forms may not carry over cleanly. These are rare in practice.
• Encryption settings. A merged output starts unencrypted unless the library is asked to re-encrypt.

For the documents people actually merge (receipts, contracts, slide decks, reports), the loss column is empty.

File order is page order

A merge tool's UI is mostly about controlling the order. The library merges in the exact sequence the user provides. File one becomes pages one through N, file two becomes pages N+1 through M, and so on. There is no automatic sorting, no duplicate detection, no interleaving.

This is why every good merge tool has drag-to-reorder. The order on the screen is the order in the output. Renaming files before uploading does not help either; the tool uses the row order, not the filename. For most workflows the order is obvious (cover page first, appendix last, receipts in the order they hit the statement), and the page-count display next to each row makes it easy to spot a misordered pair.

When merging is the wrong move

Merging is the right tool when several PDFs need to become one. It is the wrong tool in a few specific cases.

When you need to preserve digital signatures. A signed PDF cannot be merged without invalidating its signature. If the goal is to send a signed contract bundled with related documents, send them as separate attachments instead. Merging a signed document into a bundle makes the signature useless.

When the source PDFs are encrypted and you do not have the password. The library can only read encrypted PDFs after they are decrypted in memory. Without the password, the source bytes are unreadable, so the merge cannot happen. If you have the password, decrypt first (most viewers can save an unencrypted copy), then merge.

When you actually want to reorder pages within a single PDF. A reorder operation is not a merge. If the source is one PDF and the goal is the same pages in a different order, look for a "reorder pages" tool, or open the PDF in a viewer that supports drag-to-reorder at the page level. Merging the same PDF with itself in pieces produces extra pages, not a reorder.

When the result needs OCR. Merging does not run OCR. If the sources are scans that have not been OCR'd yet, OCR each source before merging, or OCR the result afterward. Trying to OCR a merged file when only some pages need it wastes time.

When file count is very high. Browser memory has limits. Merging hundreds of PDFs or several gigabytes of total content in one pass will eventually run out of memory on lower-end devices. The practical ceiling on most laptops is around 20 files and 100 megabytes total, which is also the limit in the ReezoAI tool. For larger jobs, split the merge into batches (merge the first ten, then merge the result with the next ten) or use a server-side tool.

For everything else, a browser merge is the right answer.

Why local processing matters for sensitive PDFs

PDFs are the format for documents that matter. Contracts, NDAs, tax returns, medical records, financial statements, board materials, customer agreements. The category of "documents I should not casually upload to a stranger's server" is large.

Most online PDF mergers work by uploading every file to a server, running the merge there, and returning the result. The privacy policy may say the files are deleted after an hour, but in the meantime they passed through someone else's network, queue, and logs. For sensitive content that cost is non-trivial.

A browser-based merger runs the merge inside the page. The library reads the files via the standard File API, parses them in JavaScript, builds the merged PDF in memory, and offers it for download as a blob. No fetch request carries the file content. You can verify this in DevTools: open the Network tab, start a merge, watch the panel stay empty for the upload side. The output appears as a blob URL, not a server fetch.

How the ReezoAI Merge PDF tool works

The Merge PDF tool on this site is a browser-only implementation built on pdf-lib. Drop files onto the dropzone, drag rows to set the order, click Merge, and the result downloads as merged.pdf. The original files are not modified, uploaded, or stored anywhere outside the browser tab.

The current limits are 20 files and 100 megabytes total per merge. These exist because the entire merge happens in browser memory; pushing past those numbers risks tab crashes on lower-end devices. For larger jobs, run the merge in two passes. The page works offline after the first load and discards everything when the tab closes.

Comparison with split and compress

Merge sits among the three core PDF operations:

• Merge takes many PDFs in and produces one PDF out. Non-destructive.
• Split is the inverse: one PDF in, many out, each a subset of the source pages. Also non-destructive. The Split PDF tool handles this.
• Compress takes one PDF in and produces one smaller PDF out. The size reduction comes from re-encoding images and dropping unused objects, which is destructive for image fidelity at higher levels. The Compress PDF tool offers three levels.

The three compose. A common pattern is to merge a set of source PDFs, then compress the result if the merged file is too large to email. Browser-based tools make this chain practical because the file does not get uploaded between steps.

The summary

Merging PDFs is the easy case for the format. The PDF object model is designed to combine pieces, so a merge is mostly bookkeeping. A modern browser running pdf-lib can do the entire operation locally in under a second for typical inputs, with no upload, no quality loss, and no compromise on text, image, or font fidelity. Digital signatures are the one casualty; everything else carries over.

Browser-based merging is the right default for sensitive documents because the file never leaves the device. It is also the right default for routine merges because it is faster than waiting on an upload and download. The cases where it is wrong (signed PDFs, encrypted PDFs without a password, very large jobs) are specific and recognizable.

Drop the files into the tool, drag them into the order you want, and click Merge. The output is ready before the upload progress bar would have finished on a server-side service.