Unuploaded

Merger · No upload

Merge PDF files, privately

Add PDF files, put the rows in the order you want, and download one PDF. Every page is copied byte for byte — nothing is rendered or re-encoded — and the merge runs inside your browser: nothing is uploaded at any step, and the network meter below proves it live.

Status idle Files — Pages — Output — Network since file read —

Refused by name: protected files (this page does not open protected files), cross-reference or object streams not in Flate (only Flate is read), no %PDF header or no readable page tree, past 50 files, 128 MB or 20,000 pages. Bookmarks are chained; links outside the merge are dropped and the row says how many; signatures do not carry over; tagging, the attachments panel and page labels are not carried. Takes .pdf.

The list is the page order, top to bottom. Drag a row to move it, or use its ↑ and ↓ buttons — the same job from the keyboard. That order is what Merge writes.

How this merger works

When you add a file, your browser opens it with its File API and a reader on this page walks it in memory — no transfer happens, because the file is already on your machine — from the header to the page tree. That is why each file gets a row with its page count and size before you press Merge, and why a file this page will not open gets a row saying why. Merge then writes one new file in the order the list shows. Every page, with its content, fonts and images copied byte for byte, /Filter untouched: nothing is decompressed, rendered or re-encoded, so a scan stays that scan. Form fields and annotations are carried too, but as dictionaries rewritten to the merged file's object numbers — and so is the structure around them, because two files' object numbers collide and a merged file needs one page tree. The header is the highest version any source declared, floored at 1.4; the trailer gets a fresh /ID; and there is no /Info dictionary and no document metadata stream, so nothing at the document level names a producer, author or date. An image's own embedded metadata travels inside its bytes.

The better instrument is not ours but your browser's. Press F12, open the Network tab, leave it visible, and merge: nothing of yours joins the list. On a first visit you may see this site being cached so the tools work offline; not one of those requests carries a byte of your PDF, and merging fetches nothing on any visit. That panel records what a page does rather than what it claims, and no code of ours can quiet it — which is why the meter above counts the requests this page makes from the moment your first file is read, and says so. This route is first-party throughout, so it works offline from the first page load and the meter's zero has no footnote. Compare notes with the methodology page.

The honest limits. A file that carries an encryption dictionary is refused by name the moment you add it — including one a viewer would have opened without asking anything — and a damaged file whose compressed object streams cannot be read is refused the same way, because this page cannot tell ciphertext from damage and will not rebuild either into pages. A damaged cross-reference is a different case: it is never the encrypted part, so the reader rebuilds around it and the file merges. The reader inflates only Flate, so a cross-reference or object stream under any other filter — LZW, ASCII85, a chain, a TIFF predictor — is refused naming it: a reader that cannot decode the map silently finds no pages. So is a file with no %PDF header in its first 1,024 bytes, no readable page tree or no pages. Forms are merged into one, and fields whose names collide between files are grouped under the file's name with the row saying how many; a script in one form that names a renamed field may then stop working. Named destinations are resolved, and a page whose content or resources point at nothing is counted and stated. The caps are about your device — up to 50 files and 128 MB, and 20,000 pages, each refused by name — because the whole merge sits in this tab's memory: measured in Chrome 151, thirty copies of a 4.4 MB, 126-page booklet (127 MB in, 3,780 pages) peaked at 455 MB of JavaScript heap and 849 MB of renderer memory with the finished file held for download.

Frequently asked questions

How do I merge PDF files?
Drop the PDFs onto the page, or click the drop area and choose them — up to 50 files and 128 MB. Each is read as it arrives and gets a row with its page count and size; a file this page will not open gets a row saying why, and the rest still merge. Put the rows in the order you want with a drag, or with the up and down buttons from the keyboard; the list, top to bottom, is the page order of the output. Press Merge into one PDF, and a row appears with the page count, the size and a Download link. Nothing is uploaded at any step.
Is my PDF uploaded anywhere?
No. Your browser opens each file with its File API, a reader on this page walks it in memory, and the merged file is written here and linked for download — nothing leaves your device. The network meter counts the requests this page makes from the moment your first file is read and stays at zero, and because this route fetches nothing after it loads — its reader is first-party, and cached with the rest of the site on your first visit — it works offline from the first visit, network or no network.
Why was my protected file refused?
Because this page does not open protected files. A file that carries an encryption dictionary is refused by name the moment you add it — including one a viewer would have opened without asking anything — and a damaged file whose compressed object streams cannot be read is refused the same way, because this page cannot tell ciphertext from damage and will not rebuild either into pages. A damaged cross-reference is a different case: it is never the encrypted part, so the reader rebuilds around it and the file merges. That is the whole of it: the file is left as it is.
What is kept, and what is not?
Every page, with its content, fonts and images copied byte for byte. Form fields and annotations are carried too, but as dictionaries rewritten to the merged file's object numbers. Forms are merged into one, and fields whose names collide between files are grouped under the file's name with the row saying how many. Bookmarks are chained, one chapter per file. Links that point at a page in the merge are rewritten to it; a link whose page is not in the merge is dropped, the annotation is kept, and the row says how many. Layers are unioned, so a layer hidden in a source stays hidden. Not kept: signatures, which cover byte ranges of the file they were computed over; XFA form logic; tagging, the attachments panel, page labels, the document's metadata stream, the open action and viewer preferences. A file attached to a page as a comment travels with its annotation, and an image's own embedded metadata travels inside its bytes. The output has a fresh identifier and no /Info dictionary, so nothing at the document level names a producer, author or date.
Can I combine images into one PDF here?
Not directly: this page takes .pdf files only. The JPG to PDF and PNG to PDF converters on this site each turn an image into a one-page PDF in your browser, and HEIC, WEBP and SVG have converters of their own; make a PDF from each image there, then drop those PDFs here and merge them in the order you want.

Related tools