Photo by Quilia on Unsplash
Merging two documents is straightforward. Merging forty is a document-control task. Bookmarks, form fields, mixed page sizes, rotated scans, and existing signatures all need attention, and a finished table of contents still has to point to the right pages.
This guide is for the people who deal with that at scale: proposal teams assembling bid responses, accounting departments closing month-end packets, legal support staff building exhibit bundles, and operations managers who combine PDFs as a routine part of the week rather than an occasional chore. It explains what needs checking and compares ten platforms available in the US.
The word "merge" hides several different operations:
Straight concatenation. Appending files end-to-end. Almost every tool does this correctly.
Structural merging. Preserving bookmarks, outlines, internal links, and named destinations from each source file into a single navigable document.
Mixed-source merging. Combining files with different page sizes, orientations, and embedded font sets without normalizing everything into a mess.
Interactive-content merging. Keeping AcroForm fields, annotations, comments, and layer data alive after the join.
Batch merging. Running the same operation across dozens of file sets without doing it by hand each time.
Most browser tools handle straight concatenation. The remaining operations depend on the source files and the product, so teams should test the exact features their documents use.
There are primarily 6 reasons why formatting breaks during a merge, and those are:
Mixed page geometry. A proper merge can preserve each page as it is, but a file containing Letter, A4, landscape, and portrait pages can still look uneven and print unpredictably. Standardize page size only when the final use requires it.
Bookmarks and links. Page content can survive while document-level outlines, named destinations, and internal links do not. A merge tool may preserve, rebuild, or discard them, so navigation needs a separate check.
Form field name collisions. Two forms, both containing a field called name, will either merge into one linked field that fills both at once or lose one. Neither result is what anyone wanted.
Signature invalidation. A digitally signed PDF is signed against its own byte structure. Merging changes that structure, so the signature reports as invalid. This is correct behavior, not a bug, and it is why signing should be the last step.
Limits and failed uploads. File size, page count, and task limits vary by plan. A failed component can leave an incomplete assembly, so compare source and output page counts before delivery.
Compression side effects. Tools that compress by default can re-encode images and flatten annotations. The output looks fine on screen and prints poorly.
| Platform | Merge workflow | Structure check | Automation route | Storage fit | Suits |
|---|---|---|---|---|---|
| Lumin | Browser merge and page organization | Test bookmarks, links and forms on a sample | Workspace-based workflow | Google Drive, OneDrive, Dropbox | Cloud-based teams that review together |
| Adobe Acrobat | Desktop and web assembly | Supports document-level navigation tools | Acrobat Actions for repeatable work | Adobe cloud and common business storage | Complex PDF production workflows |
| Foxit PDF Editor | Desktop and cloud PDF tools | Supports bookmarks and form work | Batch tools vary by edition | SharePoint, Box and Drive options | Teams needing a broad PDF editor |
| Nitro | Desktop-oriented PDF assembly | Supports bookmarks, links and forms | Business workflow tools | OneDrive and SharePoint environments | Windows-centered teams |
| pdfFiller | Web document assembly | Check imported forms after merging | Reusable document workflows | Common cloud-storage connections | Form and records processes |
| Smallpdf | Browser-based merge | Test advanced navigation before use | Plan-dependent processing | Drive and Dropbox connections | Regular but straightforward merges |
| Sejda | Web and desktop merge | Test bookmarks and forms | Desktop and plan-dependent tools | Local desktop or connected cloud files | Teams that want visible usage limits |
| DocHub | Browser-based page and form work | Check imported navigation and fields | Template-oriented workflows | Google Workspace and Gmail | Google-based document teams |
| PDF24 | Web and desktop tools | Check document-level navigation | Desktop tools for local work | Local files | Teams preferring device-based processing |
| Stirling PDF | Self-hosted PDF tools | Depends on configuration and version | API and administrator-managed workflows | Self-hosted | Organisations able to operate the service |
Lumin is a cloud-based PDF editor built for teams working inside Google Workspace or Microsoft 365. Files open straight from Google Drive or OneDrive, merge in the browser, and save back to the same location, which removes the download-and-re-upload cycle that generates duplicate versions during a busy assembly job. Editing, splitting, compressing, converting, annotating, and signing sit in the same product, so a document does not travel between separate tools to reach its final state.
For document-heavy teams, the collaboration model matters as much as the merge function. Lumin puts shared documents in a workspace where colleagues can comment and review together. Its paid workspace plans use team-wide document allowances. Lumin maintains a SOC 2 report, states that it meets GDPR and CCPA requirements, and uses TLS 1.2 or higher for data in transit.
Lumin also provides OCR for scanned and image-based PDFs. Even so, teams assembling long exhibit sets should test page order, navigation, forms, and output size with a real bundle before adopting any browser tool.
Adobe Acrobat combines desktop and browser tools for assembly, page reordering, OCR, forms, and document navigation. Acrobat Actions can support repeatable work. That broader feature set is useful when production checks go beyond joining pages, but it can be more than a merge-only workflow needs.
Foxit and Nitro both provide desktop PDF editing, page assembly, and business integrations. Their available batch and cloud features depend on the edition, so compare the specific plan rather than the product name alone.
Sejda and Smallpdf provide browser-based merge tools with plan limits. They suit straightforward work when the source files do not depend on complex navigation or interactive forms.
Stirling PDF deserves a mention for teams with an IT function. Self-hosting means no upload limits imposed by a vendor, no third-party retention question, and an API for batch work — at the cost of maintaining it.
Standardize inputs first. Use consistent page sizes and orientations where the final document requires them, and confirm that source PDFs display correctly before merging.
Check page counts before and after. The single most effective safeguard. Any tool that changes the total without being asked to should be replaced.
Merge before signing, never after. Signatures do not survive structural changes.
Rename form fields in source documents that will be merged to avoid collisions.
Compress as a separate, deliberate step, not as part of the merge.
Open the output in a second viewer before it goes to a client. Check page order, rotation, bookmarks, links, fields, and print preview.
At low volume, most platforms are interchangeable, and price decides. At high volume, three things decide: whether the tool preserves structure, whether it fails loudly instead of silently, and whether it fits the storage the team already uses. Test all three with a real, messy file set rather than a clean sample — the difference between platforms only appears under load.
Sometimes. Bookmark handling varies by tool and merge method. If navigation matters, test the output and rebuild the outline before delivery when needed.
The source files may use different page sizes, orientations, crop boxes, or scan resolutions. The merge can preserve those differences even when no content has changed.
Sometimes. Fields with duplicate names across source files are a common failure. Renaming fields before merging avoids it.
Yes. Limits vary by service and plan and may cover file size, page count, task count, or processing time. Self-hosted tools are still limited by their server configuration.
Discover our other works at the following sites:
© 2026 Danetsoft. Powered by HTMLy