PDF merger

Merging whole files, in the order you set

Merge several PDF files into one, in your browser: choose the files, put them in the order you want, and download the combined document. The merge takes whole files — every page of the first, then every page of the second, and so on down the list — so the one decision that matters is the order, and the list is where you make it.

• Add more files whenever you like — a later choice joins the end of the list instead of restarting it.
• Reorder with the up and down controls on each row; the combined file follows the list from top to bottom.
• Remove a file that does not belong, or clear the list. Choosing the same file twice is allowed, and means its pages appear twice.
• Each row shows the file’s name, its size, and — once the file has been read — its page count, so you can confirm you picked the right ones before merging.

Merging takes at least two files — with fewer in the list, the button says so instead of offering a pointless merge of one — and the result downloads as merged.pdf, a fixed and predictable name. A finished result never goes stale, either: change the list in any way — add, remove, reorder — and the download is taken away, because a file offered on screen must describe the list on screen.

Nothing is uploaded — not the files, and not a password

The usual way an online PDF tool works is that your file travels to a server, the work happens there, and the result comes back. Nothing of the kind happens here: the files are read in this browser tab, the merged file is written in this browser tab, and nothing you choose or type is sent anywhere. There is no upload step to trust, because there is no upload.

That matters most for exactly the documents people merge — contracts and their annexes, statements, scans of records — which are the files least suited to being handed to someone else’s server. It extends to passwords: a site that unlocks your file on its own server can only do that by receiving your password too, while here a password you type is used by your own browser to read the pages, and goes nowhere at all.

Password-protected PDFs: the two kinds of locked

A protected PDF is one of two quite different things. Some files demand a password before any viewer will show a page — an open password, without which there are no pages to merge. Others open in every viewer but restrict what may be done with them, such as printing or copying; those restrictions are flags rather than a secret, and a file carrying only them opens here on its own — the tool quietly tries an empty password first, which is all such a file needs — with a notice that the restrictions will not carry over, instead of a question you cannot answer.

• A file that needs its password shows a password field beside its own row. Type the password and unlock it there — the file is read in place, and its page count and any notices fill in.
• A wrong password is an error on that row alone, with the field still there for another try. One typo never clears the queue and never touches any other file.
• While any row still reports its file locked, merging stays off and that row says why. Nothing you queued is ever worked around either: a merge that reaches a file it cannot open stops and names that file rather than quietly leaving it out.

The owner password — the one behind a file’s restrictions — opens it here too, exactly as it does in a desktop viewer, so whichever of a file’s passwords you know is the one to type. It is used in this tab to read that one file’s pages, and for nothing else.

The merged file carries no password

Unlocking is for reading. A password you type lets the pages of that one file be read; it does not travel into the result, and the merged file comes out carrying no password at all — the page says so in plain words before you ever press merge. The sentence exists for one mistake in particular: sending the merged file on in the belief that it is still protected, because the file it was built from was.

Putting a password on a PDF is a different job, and this tool does not do it. The same goes for an input’s restrictions: a file that opened on its own but limited printing or copying contributes its pages and none of its limits, and its row said as much while you could still decide.

What a merge loses, and how this tool says so

A PDF can carry more than its pages — a digital signature, bookmarks, fillable form fields, an archival claim, usage restrictions — and merging writes a new document out of the old ones’ pages, so those extras do not come through. Most tools lose them without a word. This one raises a notice on the row of each affected file, and only when the thing is really in that file, so the notices mean something when they speak.

• A digital signature: the output will not carry a valid one, because combining pages changes the document the signature was computed over. The notice names the signed file, so a signature is never invalidated behind your back.
• Bookmarks: the clickable contents tree a viewer shows in its sidebar belongs to the document rather than to any page, and it is not carried over into the output.
• Form fields: fillable fields do not survive as a working form. Whatever a viewer still shows of them afterwards, the result is not a file to send where a form is expected to be filled in.
• A PDF/A claim: a file that declares itself PDF/A presents itself as an archival document, and the output makes no such claim about itself.
• Restrictions: a file that opened without a password but limits what a viewer may do contributes its pages with none of those limits attached.

None of these notices stops the merge — they exist so that the loss is an informed choice rather than a discovery. When what a file loses is the point of the file — the signature on a contract, the archival claim on a filing — the answer is usually to send that original alongside the merged copy rather than instead of it.

Notices that read the file, and verify nothing

The signature notice deserves its own explanation, because no merge tool anywhere can avoid this loss. A digital signature is computed over the exact bytes of the document as it stood when it was signed; a combined document is a different document, so no signature can ever cover it. That is a property of signatures, not a shortcoming of any particular tool. What differs here is only that you are told, by name, before it happens.

And the notices read the file’s own claims rather than judge them. The signature notice says that something signed the file — not that the signature is, or ever was, valid. The PDF/A notice reads the declaration in the file’s own metadata — not whether the file actually conforms to it. This tool deliberately verifies nothing: a verdict it has no basis for would be worse than no verdict, so it reports what the file says about itself and stops there.

Large files and the browser’s memory

There is no hard cap on how many files you can merge or how big they can be — nothing here refuses to try. What there is instead is a warning: beside any single file past a certain size, and under the list when the files together add up to that much, because the failure being foretold is the one no message can catch afterwards. The real ceiling is the memory this browser has at this moment — a fact about the machine rather than about your files — and a run that hits it is killed outright by the browser, not declined politely by the tool.

If that happens, the page does not leave a spinner running over nothing: it says the engine stopped mid-job — usually the browser running out of memory — that nothing was produced, and offers a retry. On a machine at its limit, the practical answer is fewer or smaller files at a time; a merged result can itself be merged again with the rest.

When a file will not open here

The file chooser does not filter by name, deliberately: what a file is gets decided by reading its bytes, so a PDF saved under the wrong extension opens normally and a mislabelled anything-else is refused in a sentence naming it. A refusal takes one of two forms, and they say different things.

• A file with no PDF header anywhere in its bytes does not appear to be a PDF at all, whatever its name says, and the refusal says exactly that.
• A file this tool cannot open is refused with a sentence about this tool, not about the file: it could not be opened here, and nothing more is claimed. PDF readers differ in how much damage they tolerate, and a file refused here may well open elsewhere.

A refusal never becomes a hole in the output. A merge that reaches a file it cannot open stops and names that file, rather than producing a combined document with something quietly missing — nothing is ever skipped on your behalf.