The files merge in the wrong order more often than you'd think
Drop cover.pdf, report.pdf, and appendix.pdf into a lot of merge tools and they hand you back appendix.pdf, cover.pdf, report.pdf โ sorted alphabetically, with the appendix opening the document instead of closing it. The tool didn't read your mind; it read the filenames. This is the single most common thing people get wrong when combining PDFs, and it stays invisible until you open the result and find the pages in the wrong sequence.
Merging is mechanically simple: you're stapling several documents into one, back to back. What trips people up isn't the stapling โ it's order, file size, and where the documents go while the tool works on them. Usually you're merging because someone on the other end wants one file, not eight:
- A loan or rental application asks for ID, two pay stubs, and a bank statement as a "single PDF." Four scans, one upload slot.
- You scanned a signed contract page by page and your phone saved each page as its own file. Twelve PDFs that need to be one.
- A report has a cover made in Word, a body exported from Google Docs, and charts saved from a spreadsheet โ three sources, one deliverable.
- You're archiving receipts and want one file per month instead of forty loose ones.
In every case the goal is the same: fewer files, in a fixed order, that open as one document.
The privacy part, honestly
Most "merge PDF" websites work by uploading your files to their server, combining them there, and sending back a download. That's fine for a meeting agenda. It's not fine for a bank statement, a passport scan, a medical form, or a signed contract โ which are exactly the documents people merge, and exactly the ones you don't want sitting on a stranger's server, even briefly.
Browser-based tools handle this differently. Merge PDF on everyboringtool.com runs entirely in your browser: the files are read into your device's memory, combined locally, and handed back as a download. Nothing is uploaded, there's no account, and closing the tab wipes everything. You can check this yourself โ open the tool, turn off your Wi-Fi, and it still works. If it needed a server, it couldn't.
That's the honest version of the privacy claim. It isn't "military-grade encryption" โ there's no encryption involved, because the file never travels anywhere to need protecting.
Getting the page order right
Since order is where people slip, do it deliberately:
- Rename before you start, or reorder after you add. If the tool sorts by filename, prefix them
01-cover,02-body,03-appendixso alphabetical and intended order are the same thing. If it lets you drag to reorder โ most browser tools show a list or thumbnails โ ignore the names and just drag. - Check the seams. After merging, jump to the pages where one document ends and the next begins โ say page 2 and page 3 if your first file was two pages. That's where an out-of-order or missing file shows up. You don't need to read all 40 pages; you need to read the four or five transition points.
- Watch for a stray blank page. A source PDF built for double-sided printing sometimes carries a trailing blank to force the next section onto a fresh sheet. It's harmless but looks sloppy in an application. If you spot one, split it out or re-export that source without it.
A worked example: you're combining a 2-page cover letter, a 3-page rรฉsumรฉ, and a 1-page reference list. The merged file should be 6 pages, with the rรฉsumรฉ starting on page 3 and references on page 6. If it's 6 pages but references land on page 4, a file went in out of order. If it's 7 pages, something carried a blank. Two quick checks catch both.
When to compress the result โ and when not to
Merging doesn't shrink anything. Ten 4 MB scans become one ~40 MB file, and that's the second thing that bites people: the upload slot that asked for "one PDF" often caps it at 10 MB.
Phone and flatbed scans are the usual culprit. A single scanned page saved as a high-resolution image inside a PDF can run 3โ6 MB on its own; text-based PDFs exported from Word or a browser are a fraction of that. So a 40-page merged report of typed pages might land at 2 MB, while a 12-page merged file of scans hits 50 MB.
Compress after merging when the combined file is over the recipient's limit (often 5, 10, or 25 MB for email and web forms), and when the pages are scans or photos, where there's real image data to squeeze. Skip the compressor when the pages are already text-based exports โ you'll shave off kilobytes and possibly soften the text for nothing. Merge first, check the size, and only reach for a compressor if the number is actually a problem.
When merging in the browser isn't the right approach
Browser-based merging leans on your device's memory, and that's a real ceiling. A dozen typed-text PDFs are nothing. But drag in 300 high-resolution scans totaling 800 MB and a modest laptop or a phone will stall, freeze the tab, or run out of memory partway through โ every one of those files has to sit in RAM at once. There's no server absorbing the load; it's all local, which is the privacy upside and the scaling limit in one.
For genuinely large jobs, a desktop application that streams files from disk instead of loading them all into memory will handle it more gracefully. Same story if you need to merge on a schedule, hundreds of times a day โ that's a script's job, not a web tool's.
One more honest edge: browser tools merge, they don't repair. If a source PDF is corrupted or password-protected, merging won't fix or unlock it; you'll need to sort that file out first.
Before you send it
Name or drag your files into deliberate order. Merge. Then open the result, check the two or three page numbers where documents meet, and glance at the file size. Under the recipient's limit? You're done. A pile of scans that's too big? Compress once and re-check. That five-second inspection at the seams is the difference between sending a clean single document and re-doing it after someone bounces it back.