Merging copies page objects from each source file into one new document. Nothing is re-rendered, so text stays sharp and images keep their exact resolution. The output is roughly the sum of the inputs.
Three things are at risk: certificate signatures, which always break, some internal page links, and the tagged structure screen readers rely on. Sign and tag after merging, never before.
You have a cover letter, a CV and a portfolio, and the application portal wants one file. Or four scanned invoices that belong in a single expense claim. The task is trivial and the tools are everywhere, which is exactly why most people never stop to ask what the merge is doing to their document.
It is worth knowing, because a merge is not a neutral operation. Most of the file comes through untouched. A few specific things get quietly dropped, and if you do not know which ones, you find out at the worst moment, usually when a recipient tells you the signature is invalid.
What a merge does to the file
A PDF is a collection of numbered objects with an index at the end pointing at each one. Pages are objects. Fonts, images and colour profiles are objects. A page object does not contain its own content so much as it references the content streams and resources it needs.
Merging walks that structure. It copies the objects from each source document into a single new file, renumbers them so nothing collides, and builds one page tree listing every page in the order you asked for. The content stream that described page four of your second file is byte-identical in the output. It just answers to a different number now.
Pages are copied, not re-encoded. No generation loss, no resampling, no recompression of images.
Nothing is recompressed, so the output weighs roughly what the inputs weighed together, plus a little structure.
A merge writes a new file, and a certificate signature only holds for the exact bytes it was made over.
This is why merging is one of the safest things you can do to a PDF. Compression throws data away. Conversion re-interprets the layout. A merge mostly just reshuffles the index. If the pages looked right going in, they look identical coming out.
Merging in the browser, step by step
Anything that runs on your own machine is preferable here, because the alternative means handing a complete document to a server you know nothing about. Browser-based tools read the file into memory, do the work in JavaScript or WebAssembly, and hand you back a download. The file never crosses the network. PDFslime's Merge PDF tool works this way, using the pdf-lib library, and takes PDFs and JPEG, PNG or WebP images in the same list.
Add every file before you start ordering
Load all of them first. Reordering is quicker when the full set is on screen, and it saves you discovering a missing document after you have already arranged eight others.
Put them in reading order, not file order
The order in the list is the order in the output. Drag the cover to the top and the appendix to the bottom, or use the arrows on each row. Files arrive in whatever order the browser hands them over, which is not always the order you picked them in.
Merge, then open the result before you send it
Scroll the joins. The seam between two documents is where page-size jumps and upside-down scans announce themselves, and it takes about ten seconds to check.
Getting the page order right the first time
Almost every complaint about merged PDFs comes down to order, and almost every one of those traces back to the same cause. The tool sorted by filename and the filenames sorted in a way you did not expect. The guide to merged PDF pages in the wrong order covers repairing a file that already came out scrambled.
Computers sort text one character at a time. Under that rule page10.pdf comes before page2.pdf, because the character 1 sorts before the character 2. The fix is to pad the numbers so every filename is the same length: page02.pdf and page10.pdf sort correctly, and so does anything named with a leading zero. PDFslime's merge tool never sorts on its own. Its Sort by name button reads runs of digits as numbers, so page2 lands before page10 there, and Reverse flips the whole list.
01-cover, 02-body, 03-appendix survives every tool, every operating system and every colleague who reorganises your folder.What survives the merge and what does not
The page content is the easy part. The interactive layer sitting on top of the pages is where merges get interesting, because those elements were written assuming a document that no longer exists.
- Page text and layoutAlways intact
- Images and their resolutionUntouched
- Highlights and commentsUsually kept
- Form fieldsKept, clashes possible
- Bookmarks and outlineTool dependent
- Internal page linksTest them
- Digital signaturesAlways invalidated
- Tagged reading orderUsually lost
Internal links break for a reason worth understanding. A link that jumps to page twelve does not store the words "page twelve". It stores a reference to a specific page object. When the merge renumbers everything, some tools update those references and some do not. If your source document had a clickable table of contents, test it in the output before you assume it came through. Bookmarks are a separate structure: PDFslime's merge reads each file's bookmarks, shifts them to the new page numbers, and can add one bookmark per source file.
Merging documents that contain form fields
Two filled forms merged together will often show the same value in both copies of a field, or lose one set of answers entirely. The cause is name collision. Form fields are addressed by name, and if both documents contain a field called full_name, the merged file now has two fields claiming the same identity.
Readers resolve this inconsistently. Some rename the second one, some link them so typing in either updates both, some silently drop it. PDFslime's merge avoids the clash by keeping the form definition from the first file that has one. If you need to combine completed forms and keep every answer, flatten each form first. Flattening turns the filled values into ordinary page content, which merges without any of this ambiguity.
Why the upload step is worth avoiding
Merging is usually the last step before a document goes somewhere important, which means the files involved are rarely trivial. Contracts, medical records, tax paperwork, anything with a signature block. The convenience of a web tool is real, and so is the cost of handing all of that to an unknown server.
The file stays on your machine
- Nothing crosses the network, so nothing can be intercepted
- No retention policy to read, because there is no copy to retain
- Works offline once the page has loaded
- No account, no email address, no queue
The file becomes someone else's problem
- A complete copy sits on hardware you do not control
- Deletion promises are policy, not physics
- Large files upload twice, once up and once back down
- Often gated behind sign-up or a daily limit
For a recipe collection it hardly matters. For a signed lease or a patient record it matters a great deal, and since the browser-based version is not slower or harder, there is little reason to make the distinction case by case.
Habits that keep merged PDFs tidy
Once merging is routine, a few small practices stop the predictable problems from ever reaching a recipient.
Open the merged file and scroll past each join. Mixed page sizes and rotated scans are obvious there and easy to miss anywhere else.
Compress once, after the merge. Compressing each input and then merging gives a worse result than merging first and compressing the whole thing in one pass.
Keep the sources until the merged file is delivered and accepted. Re-merging from clean inputs beats trying to repair an output.
Flatten filled forms before they go in. It removes the field-name collisions before they happen and costs nothing if the form was already final.
Merge PDFs in your browser
Drag to reorder, combine as many files as you like. Nothing is uploaded and nothing is tracked.
Common questions
The things people discover halfway through a merge.
01Does merging PDFs reduce quality?
No. Merging copies page content across without re-encoding anything, so text stays vector-sharp and images keep the exact resolution they had in the source. There is no generation loss no matter how many times you merge and re-merge. Compression is the operation that costs quality, and it is a separate step.
02Why is my merged file so large?
Because merging adds rather than compresses. Each source brings its own images and fonts, and PDFslime's merge copies them per file without looking for duplicates, so ten letters on the same letterhead carry the letterhead image ten times. If the result needs to be smaller, compress the merged document in one pass.
03Can I merge password-protected PDFs?
It depends on the password. A file that opens without asking but restricts printing or editing carries only an owner password, and PDFslime's merge opens those as they are. A file that asks for a password before it opens has to be unlocked first: remove the password from a document you own, merge, then protect the finished file if it still needs it.
04Why did my pages come out in the wrong order?
Almost always filename sorting. Text sorts one character at a time, so page10 lands before page2. Rename with padded numbers such as 02 and 10, or drag the files into position manually before merging rather than trusting the order they loaded in.
05Will my table of contents still work after merging?
Sometimes. Internal links point at specific page objects, and merging renumbers every object in the file. Tools that update those references keep the links working, and tools that do not leave them pointing nowhere. Test a couple of entries in the output before you rely on it.
06Is there a limit to how many files I can merge?
In the browser the practical limit is memory rather than a policy. Every page has to be held in RAM while the new file is assembled, so a few hundred pages is comfortable on any modern machine and several thousand may not be. If a very large merge stalls, do it in two halves and merge the halves.