merge multiple PDF files into one document. drag to reorder. 100% client-side — your files never leave your browser.
drop PDFs here
or click to browse — up to 10 files
Drop two or more PDFs in, drag them into the order you want, hit merge, and you get back a single combined PDF. The whole operation runs in your browser — your files never reach a server, because there isn't one in the loop. The merged file is generated locally and downloaded directly from the tab you have open.
That is the entire user-facing description. The rest of this page is for people who want to know why it works that way, and what it does and does not handle.
A PDF is a structured binary container. Every page lives as an object inside the file, and the document keeps a tree (the /Pages tree) that lists which pages belong to the document and in what order. Merging two PDFs is not about gluing bytes together — it is about copying pages from each source document into a new /Pages tree.
Persimmon uses pdf-lib for the structural work. The actual merge logic looks roughly like this:
import { PDFDocument } from "pdf-lib";
async function mergePdfs(files: File[]): Promise<Blob> {
const out = await PDFDocument.create();
for (const file of files) {
const bytes = await file.arrayBuffer();
const src = await PDFDocument.load(bytes);
const pages = await out.copyPages(src, src.getPageIndices());
pages.forEach((p) => out.addPage(p));
}
const merged = await out.save();
return new Blob([merged], { type: "application/pdf" });
}copyPagesis the important call. It clones every page object the source references — including embedded fonts, images, annotations, and form fields — into the destination's object table. The result is a structurally valid new PDF, not a stitched-together hybrid.
Preserved across a merge:
Things that can get tricky:
Most PDFs you handle in any given month are sensitive: signed contracts, scanned IDs, tax forms, medical bills, leases. The default model for online merging is to upload your file to a server you have never heard of, run the merge there, and trust the operator to delete it on schedule. There is no way to verify the deletion happened — or that the file did not end up in a backup, cache, or analytics pipeline along the way.
The check you can run yourself
We wrote a longer piece on the architectural reasoning behind this: Why every PDF tool on Persimmon runs in your browser.
Browser memory is real and finite. A typed array in a single page caps around 2GB on most browsers, and practical performance degrades well before that. For typical document workflows (contracts, scans, reports under a few hundred MB) this is a non-issue. For archival merges of multi-GB files, you will hit a wall.
If your source PDFs are scans without a text layer, the output will also have no text layer — merging does not perform OCR. We do not currently offer client-side OCR because the available WebAssembly OCR runtimes are slow and inaccurate compared to purpose-built services.
The merge does not re-encode or recompress page contents. If your sources have large embedded images, the merged file size will be roughly the sum of the inputs. If you need a smaller output, run the result through a PDF compression tool afterward.
For the inverse operation — pulling specific pages out of a PDF into separate files — see the PDF split tool. For converting a merged PDF into a sequence of images for embedding elsewhere, the PDF to images tool handles that without a server either.
Drop two or more PDFs in, drag them into the order you want, hit merge, and you get back a single combined PDF. The whole operation runs in your browser — your files never reach a server, because there isn't one in the loop. The merged file is generated locally and downloaded directly from the tab you have open.
That is the entire user-facing description. The rest of this page is for people who want to know why it works that way, and what it does and does not handle.
A PDF is a structured binary container. Every page lives as an object inside the file, and the document keeps a tree (the /Pages tree) that lists which pages belong to the document and in what order. Merging two PDFs is not about gluing bytes together — it is about copying pages from each source document into a new /Pages tree.
Persimmon uses pdf-lib for the structural work. The actual merge logic looks roughly like this:
import { PDFDocument } from "pdf-lib";
async function mergePdfs(files: File[]): Promise<Blob> {
const out = await PDFDocument.create();
for (const file of files) {
const bytes = await file.arrayBuffer();
const src = await PDFDocument.load(bytes);
const pages = await out.copyPages(src, src.getPageIndices());
pages.forEach((p) => out.addPage(p));
}
const merged = await out.save();
return new Blob([merged], { type: "application/pdf" });
}copyPagesis the important call. It clones every page object the source references — including embedded fonts, images, annotations, and form fields — into the destination's object table. The result is a structurally valid new PDF, not a stitched-together hybrid.
Preserved across a merge:
Things that can get tricky:
Most PDFs you handle in any given month are sensitive: signed contracts, scanned IDs, tax forms, medical bills, leases. The default model for online merging is to upload your file to a server you have never heard of, run the merge there, and trust the operator to delete it on schedule. There is no way to verify the deletion happened — or that the file did not end up in a backup, cache, or analytics pipeline along the way.
The check you can run yourself
We wrote a longer piece on the architectural reasoning behind this: Why every PDF tool on Persimmon runs in your browser.
Browser memory is real and finite. A typed array in a single page caps around 2GB on most browsers, and practical performance degrades well before that. For typical document workflows (contracts, scans, reports under a few hundred MB) this is a non-issue. For archival merges of multi-GB files, you will hit a wall.
If your source PDFs are scans without a text layer, the output will also have no text layer — merging does not perform OCR. We do not currently offer client-side OCR because the available WebAssembly OCR runtimes are slow and inaccurate compared to purpose-built services.
The merge does not re-encode or recompress page contents. If your sources have large embedded images, the merged file size will be roughly the sum of the inputs. If you need a smaller output, run the result through a PDF compression tool afterward.
For the inverse operation — pulling specific pages out of a PDF into separate files — see the PDF split tool. For converting a merged PDF into a sequence of images for embedding elsewhere, the PDF to images tool handles that without a server either.
PDF utilities, image tools, developer helpers — all free, no signup.
Convert multiple images into a single PDF document.
Split a PDF into individual pages or custom ranges.
Pick colors, generate harmonious palettes, and export as HEX, RGB, or HSL.
Generate strong, random passwords with customizable length and character sets.
Count words, characters, sentences, paragraphs, and reading time in real-time.
Generate lorem ipsum placeholder text by paragraphs, sentences, or words.