Why merge in the browser
Merging PDFs is the most ordinary task imaginable, and the documents involved are rarely ordinary. Joining a contract to its annexes, a set of payslips, a medical history, a passport scan and a bank statement, these are exactly the files that should not be handed to an anonymous web service that offers no explanation of what happens to them afterwards.
This tool reads your files with JavaScript running on your own machine, builds the new document in memory, and hands it back. There is no server involved, no queue, and no retention policy to read, because there is nothing to retain.
Order matters more than you expect
Applications are usually reviewed in the order the documents appear, and a checklist that says "proof of identity, proof of address, proof of income" expects that sequence. Files selected from a folder arrive in filename order, which is rarely the same thing.
Drag them into order by their handles (or use the arrows) before merging, and check the first page of each section afterwards.
Merge first, compress once
If the combined file has to fit a size limit, do it in this order:
- Merge everything into one document.
- Compress the merged file once, to the limit.
Compressing each part separately and then merging gives a worse result, because each file is squeezed without knowing how much of the budget the others will use. Compressing once, at the end, spends the whole allowance intelligently across every page.
When to split instead
Sometimes the answer is fewer pages, not smaller ones. If a portal wants a single certificate and you have a 40-page bundle, no amount of compression produces a readable file, use the split tool to extract just the pages required.