Whether you're stitching together a set of scanned receipts, combining chapters into one manuscript, or assembling a client packet out of separate contracts, merging PDFs is one of those tasks people assume needs Adobe Acrobat. Merge PDF does it entirely in your browser — nothing you select ever leaves your device.
This guide covers the merge itself, the details that make the difference between a clean result and a messy one, and the honest limits of what survives the trip from many files into one.
How to merge PDFs with PDFlyHQ
- Open Merge PDF and drop in two or more files, or add them one at a time — you can keep adding more before you merge.
- Every page from every file lands in one thumbnail grid, in the order the files were added.
- Drag any page to reorder it — you can move a page from the second file ahead of pages from the first, mix and match freely.
- Hover a page to rotate or delete it if you don't want it in the final document.
- Click Merge PDF. Nothing about the order, rotation, or deletions is finalized until that click.
Because nothing finalizes until the final click, this is a safe place to experiment — drag a page somewhere, see the grid react, drag it back if you change your mind.
Getting the page order right
Because merging pools every page from every file into one grid rather than treating each file as an indivisible block, you're not limited to "file A then file B." If you need page 3 of the second document to appear right after page 1 of the first, just drag it there. Files can also be sorted alphabetically by name (A→Z or Z→A) if you added a lot of them and want a quick starting order before fine-tuning by hand.
Page-level control sounds like a nicety until the first time a merge genuinely needs it. The classic case: an application packet where the cover letter must precede the resume, the resume the references, and the references the certificates — but the certificate PDF also contains an irrelevant page 3 you don't want at all. With file-level merging you'd need a separate page-deletion step first; with a page grid, deleting that page is one hover and one click, mid-merge.
Interleaving works the same way. If the plan is "report page, then its appendix chart, then the next report page," that's just dragging — the grid doesn't care which file a page originally came from.
What merging is actually good for
The unifying reason to merge is that one document travels better than many. Concretely:
- Email — one attachment instead of five; nothing gets lost in an attachment list, and the reading order is the sending order.
- Printing — one print job with consistent settings, instead of five jobs that come out of the tray in whatever order the printer felt like.
- Client and application packets — contract, exhibits, signature page; cover letter, resume, references — assembled once, received as the finished bundle.
- Scattered scans — a week's receipts scanned one at a time become a single monthly expense file.
- Archiving — related documents stored as one unit, so future-you finds "the 2026 contract file," not seventeen nearly-identical PDFs.
What doesn't survive a merge
Merging copies pages into a brand-new PDF rather than literally concatenating the original files, so a few things don't come along for the ride: bookmarks/outlines from the source documents aren't carried over, and interactive form fields or annotations may not survive intact. If any source file is password-protected, the merged output is rebuilt without that protection — you'll see a warning before it happens. A file that needs a password just to open can't be read here at all; run it through Unlock PDF first if you have the password.
The form-field point deserves a practical tip, because it bites people who least expect it. If a source document is a filled form — an application completed in a PDF form, say — and the field values matter, flatten it first with Flatten PDF. Flattening bakes the answers into the page itself as ordinary content, so what the merge copies is exactly what you see on screen. It's the difference between merging a document and merging a picture of it — for these purposes, the picture is what you want.
None of these caveats affect the pages themselves: text, images, and layout carry over exactly. What can be lost is the interactive scaffolding around them — the parts of a PDF that aren't strictly page content.
Polishing the merged result
A merge of separately-created documents often shows its seams — different page sizes, mixed orientations, pages numbered 1, 2, 1, 2 from the two sources. Two quick passes fix the common ones:
- Orientation and stray pages — handle these in the grid before merging: rotate the sideways scan, delete the blank page the scanner always adds at the end.
- Page numbers — sources almost never number compatibly. Add Page Numbers renumbers the merged document as one continuous sequence, which a 60-page assembled packet badly needs ("see page 34" should mean one thing).
Mixed page sizes (A4 next to Letter, say) are preserved honestly rather than silently rescaled — each page keeps its original dimensions. If uniformity matters, align your sources before merging rather than expecting the merge to normalize them.
When to merge vs. when to keep files separate
Merging makes sense when a reader genuinely needs everything in one place — a single PDF is easier to email, print, or archive than five separate attachments. If instead you want to pull specific pages OUT of an existing document rather than combine multiple ones, that's the opposite job — see Split PDF.
It's also worth naming when merging is the wrong move. Keep files separate when different documents go to different recipients; when pieces get updated independently (merging again for every revision is its own chore); or when the total size would exceed what the channel accepts — several moderate attachments can beat one enormous file. The test is simple: if the documents share one audience and one purpose, merge; if not, don't.