Merge PDF Files — Combine Multiple PDFs Online for Free

A contract made of separate scans, a report built from individual exports, a bundle of receipts — you often need to combine several PDFs into a single file and set the page order. The "Merge" tool in pdfredX joins files right in your browser: you drag pages into the sequence you want and download one unified PDF. Nothing is uploaded to a server.

Step 01. Load the PDF files

Open pdfredx.com and drag two or more PDFs into the drop area — or pick them through your file browser. Files are read locally via FileReader, and pages are rendered to a Canvas through PDF.js. Not a single byte leaves your device.

Each source file in the gallery gets its own color label — a stripe on its cards. That is not decoration: through an internal pdfSrcKey the app remembers which document each page came from, so nothing gets mixed up during assembly.

Step 02. Arrange the pages

The order of pages in the final file is the order of cards in the gallery. Drag cards with a mouse or a finger: a page moves to its new spot and the rest shift over. Unneeded sheets can be removed with the 🗑 button on the card.

Dragging works on touch screens too: a short activation threshold (~9 px) tells a deliberate drag from an accidental tap, so the gallery does not "jump" while you scroll on a phone.

Step 03. Download the single PDF

Press "Create PDF". The app walks the gallery and assembles every page into one file through jsPDF: for each page the orientation (portrait or landscape) is chosen automatically from its proportions, on A4 sheets. The finished document downloads straight from the browser. Free, no sign-up, no waiting in a server queue.

How it works under the hood

Merging runs through a raster pipeline rather than a merge of the binary PDF structure. PDF.js renders each page of each file to a Canvas and stores it as a dataURL in the shared items[] array — with the source key pdfSrcKey. Order in the array = order in the gallery; Drag & Drop on Pointer Events simply reorders items[] elements, without re-rendering.

On output jsPDF walks items[]: for each page it calls addImage(editUrl, ...) and picks the A4 orientation by the image proportions. The file is built entirely in the tab's memory and handed to the browser for download.

Known limitations

The result is raster. Pages are inserted as images, not as vector text. In the final file text cannot be selected or copied — it is part of the picture. If you need a text layer on a specific page, apply area OCR after assembly.

Hyperlinks and bookmarks are not carried over. Rasterization preserves the look of the page, but interactive elements of the source PDFs (links, tables of contents, form fields) do not make it into the image.

Memory on large bundles. Hundreds of pages means hundreds of images in the tab's RAM. On weak devices, 200+ pages can cause scrolling to stutter.

Need the reverse operation — cut a large document into parts or pull out individual pages? That is the Split PDF tool.

Try it right now — pdfredx.com, no registration, your files stay with you.

Bundling financial reports, passport scans, HR documents or bank statements into one file is a routine task. But to simply combine a few PDFs, an ordinary online service asks you to upload all the files at once to its server. That means your whole package of confidential documents travels to someone else's machine — for an operation that boils down to putting pages in order. Let's look at the risk and at the local alternative.

Where your documents go on server-side merge services

When you upload a PDF to a typical online merger, each file travels in full to a remote machine. From there it follows the service's policy, which few people ever read:

• files are stored in a contractor's temporary storage (AWS, GCP, Azure);
• they are processed on someone else's server;
• they are kept from a few hours to several days "for reliability";
• they are logged together with metadata — IP, time, file names and sizes.

With merging the risk is even higher than with processing a single file: you send several documents at once. If those are financial reports, scans with personal data or contracts — the entire package ends up on a third-party machine in one go.

Full isolation in the browser: how pdfredX merges

pdfredX does not upload your files to any server. That is a consequence of the architecture, and you can verify it.

Files are read locally. PDF.js opens each document inside the tab through FileReader and draws the pages to a Canvas. There is no network request carrying your files.

Assembly happens in the tab's memory. Page order, Drag & Drop rearrangements, the final jsPDF composition — all of these are operations on data from files that are already loaded. Nothing is sent anywhere.

The finished file is built on the client. jsPDF forms the single PDF right in the tab and hands it to the browser for download — into your "Downloads" folder, not to a server and back.

It works offline. Load the files, turn off the internet and assemble the document — everything keeps working. The network is only needed to load the app once.

Step by step, without sending anything to a server

01. Load the PDFs. Drag the files into the drop area on pdfredx.com. FileReader reads them locally — they do not leave your device.

02. Set the order. Drag the page cards into the sequence you need; remove the extra ones. Color labels help you keep source documents apart.

03. Save and close. Press "Create PDF" — jsPDF assembles the single file locally. Once you close the tab, the file data disappears from memory.

What we cannot guarantee — an honest disclaimer

Client-side processing protects documents from being sent to external servers, but it is not a shield against every threat, and promising otherwise would be dishonest.

Malware or a keylogger on the device. If the machine is compromised, a program can read files off the disk bypassing the browser entirely.

Browser extensions with broad permissions. An extension with "read data on all sites" access can, in theory, see the tab's contents. For sensitive documents, work in a profile without third-party extensions or in a private window.

The saved file stays on your disk. If the device is not protected by encryption, confidential files can be read by third parties with physical access.

We provide isolation at the level of the browser tab. The rest is on the user's side.

Merge a package of documents without uploading to a server — pdfredx.com, free, no registration.

Merging several PDFs on a server is easy: accept the files, parse the structure, splice the object trees, return the result. In the browser, with no backend and no file uploads, the set of constraints is different — and the architectural choice is not obvious. Let's break down how the merge tool in pdfredX is built: why a raster pipeline instead of a binary-structure merge, how page order rests on a single array, and where it runs into memory limits.

The architectural challenge and the stack choice

Merging PDF structure vs. rasterization. The PDF format is a complex binary graph: cross-reference tables, object streams, fonts, resources. Libraries like pdf-lib can splice such structures without rasterizing, preserving the text layer. But on real-world files — with scans, non-standard metadata, corrupted xref tables — the stability of such a merge is lower, and you have to drag a full parser into the browser.

Why the PDF.js → jsPDF path was chosen. pdfredX renders pages through PDF.js (the industry standard for PDF rendering) and assembles the result through jsPDF. The pipeline is predictable on files of any origin: if PDF.js could show a page — it will land in the output. The price of that reliability is the loss of the text layer: every page becomes an image. For merging scans, where the sources are raster to begin with, that is an acceptable trade-off.

Why everything is local. PDF.js renders in the tab, jsPDF assembles there too. Files never go to a server — that is both faster (no round-trip) and more private (the package of documents stays on the device).

The implementation, piece by piece

A single source of truth — the items[] array

Each loaded PDF is rendered page by page. The render result of every page is converted to a dataURL and pushed into the shared items[] array. Each element carries a source key:

items.push({
  id, name,
  origUrl,             // dataURL of the original — never mutated
  editUrl,             // current dataURL (for merge = origUrl)
  fromPdf: true,
  pdfSrcKey,           // key of the source file → color of the label in the gallery
});

pdfSrcKey ties a page to its source file: in the gallery it is a colored stripe, and in code it is a guarantee that documents will not get confused during reordering. The order of array elements is the order of the future document.

Reordering pages: Drag & Drop on Pointer Events

Order is set by dragging cards. The implementation runs on Pointer Events (one code path for mouse and touch), with a drag-start threshold:

if (Math.hypot(dx, dy) < 9) return;   // not a drag yet — jitter or a tap
// otherwise: lift a ghost clone of the card, move it, on release — splice in items[]

The 9 px threshold separates an intentional drag from an accidental touch while scrolling — critical on phones. The move itself does not re-render pages: only the element's position in items[] changes.

Assembly: jsPDF over the array

The final file is assembled by makePDF():

let pdf = null;
for (let i = 0; i < items.length; i++) {
  const { w, h } = await imgDims(items[i].editUrl); // page proportions
  const orient = w > h ? 'landscape' : 'portrait';  // orientation by proportions
  if (i === 0) pdf = new jsPDF({ orientation: orient, unit: 'mm', format: 'a4' });
  else         pdf.addPage('a4', orient);

  // Fit the page into the sheet keeping proportions (contain), then center it
  const pw = pdf.internal.pageSize.getWidth();
  const ph = pdf.internal.pageSize.getHeight();
  const ratio = w / h;
  let dw, dh;
  if (ratio > pw / ph) { dw = pw; dh = pw / ratio; }
  else                  { dh = ph; dw = ph * ratio; }
  const x = (pw - dw) / 2, y = (ph - dh) / 2;

  const fmt = items[i].editUrl.startsWith('data:image/png') ? 'PNG' : 'JPEG';
  pdf.addImage(items[i].editUrl, fmt, x, y, dw, dh, '', 'FAST');
}
pdf.save('merged.pdf');

Two key details. First, imgDims is called for each page separately — this matters for mixed bundles: a contract in portrait, appendices in landscape (a common case when merging heterogeneous scans). Second, the page is fit into the sheet keeping its proportions (contain) and centered — dw/dh are computed from the aspect ratio, and the margins stay white. The image is not stretched to fill the whole A4, so a scan's proportions are never distorted.

Performance trade-offs and memory limits

The cost of raster storage. Each page is a JPEG dataURL. An A4 sheet at 150 DPI, once decoded, is roughly an 8.7 MB RGBA bitmap in memory. On a bundle of 100 pages the decoded bitmaps take up close to 870 MB; Chrome caps a tab at around 2–4 GB and, as it approaches the limit, starts evicting inactive objects, causing re-renders while scrolling.

The export spike. jsPDF holds the whole document in memory until save(). On 200+ pages the peak usage at assembly time is 2–3× higher than during ordinary gallery viewing: decoded bitmaps, jsPDF's internal buffers and the final blob all live at once.

What could be improved. Streaming export via WritableStream would remove the peak memory spike on very large bundles — that is on the roadmap.

What's next

Optional text-layer preservation for purely digital (not scanned) PDFs — a separate branch through a structure merge, when the sources allow it.

An LRU cache of decoded bitmaps — keep only the last N pages at full resolution, the rest compressed, to cut peak memory by an order of magnitude.

Want to test it under load — load several multi-page PDFs on pdfredx.com and assemble a single document. No registration, no file uploads to a server.