PDF merging: choose files, order and destination
Ten recorded document interfaces show how PDF merging makes source identity, file order, page totals and the new output understandable.
A mobile PDF merge flow should let a person identify the source files, verify their order and recognize the new document that will be created. Selecting several rows is only the beginning. A successful merge in the wrong sequence can still produce a document the user cannot confidently send.
Keep file count, page count and output count distinct. Two source files might contain six pages, and a tool may produce one combined PDF or several separate files depending on the chosen operation. The interface should explain that contract before asking for a filename or showing a final Merge action.
These ten recorded interfaces show source lists, ordering controls, naming fields and output choices. They do not establish file-processing fidelity or the handling of every protected document. Use the comparisons to design the visible workflow, then verify the actual artifact and failure behaviour with representative files.
Show which files were selected and what the numbers mean.
PDF Scanner AI marks selected documents with order badges such as one and two. Scan to PDF Document Scanner shows selected rows within a dated file list. The first can communicate sequence as well as membership; the second needs an additional way to explain whether the list order becomes the merge order.
Do not rely on tap order unless people can see and revise it. A user might select documents while searching through a list sorted by date, then expect the result to follow another order. If numbered badges encode the sequence, keep them stable and update the visible summary whenever a file is removed.
Before proceeding, show a reviewable list of the actual sources. A count of two selected items is not enough when several files have similar names. Include a useful thumbnail, filename and page count when those facts are available. Make the empty and one-file states explicit rather than letting an unavailable action look like a broken button.


Provide a dedicated way to review the merge sequence.
Forma places two source files in a merge view, labels their page counts and tells people they can move files to change the order. CamScanner gives a long-press instruction for manual sorting and displays drag handles. Both expose ordering as a task the user can perform, not a hidden consequence of selection.
The order view should refer to whole source documents when that is the operation. Do not imply that dragging a file row rearranges pages inside it. If a later step offers page-level editing, name it separately. Moving a four-page source ahead of a two-page source changes the boundary between documents, not their internal page sequences.
Provide an accessible alternative to long-press dragging, such as move earlier and move later actions with clear item names. Keep focus on the moved item and announce its new position. Reordering should remain predictable with long filenames, large text and a list that extends beyond one viewport.


Help people distinguish similar filenames and revisions.
Smallpdf’s order view includes two differently sized versions of a UI Design file, with drag handles and a Merge 2 files action. Atlas AI shows a merged-document sheet over a selection context, with a reorderable list and Save. These views make source identity important even after the membership decision has been made.
A compressed copy and its original can have nearly identical thumbnails. Show enough identity to distinguish them, using verified name, size, page count or a preview rather than forcing the user to guess. If names are truncated, allow the full value to be inspected without losing the current order.
Use the final action label consistently with the operation it triggers. Save might commit a prepared file or begin creation; a screenshot alone cannot settle that. In your product, distinguish confirming the plan, generating the document and saving the completed artifact. Do not announce completion just because the merge sheet closed.


Keep source selection and output naming connected.
PDF Editor shows an empty Combine PDF state with source placeholders, a Choose file action, an output-name field and an unavailable Save. PDF App Convert Create Sign shows a populated Merge Files flow with source rows, Add more, a name input and Merge. The transition between these states should retain a clear explanation of what is missing.
Use a sensible proposed filename without silently replacing an existing document. If the chosen destination already has that name, resolve the conflict before committing. Adding another source should not reset a carefully typed name, and editing the name should not discard the ordered selection.
An unavailable primary action should have a discoverable reason. If two sources are required, explain that requirement near the source list. If a protected or unavailable file blocks progress, identify it specifically and offer a repair path. A generic disabled button gives no help to someone who believes they have completed the form.


Explain whether the result is one file or many.
SCANACE includes an output name, an existing document with a page count, Add Documents and Merge. PDF Scanner Editor Converter offers a choice between merging all images into one PDF and creating a separate PDF for each image. These controls address a different question from output format: how many artifacts will be created?
Do not treat two pages in one source as evidence that two files have been selected. Name the units in the summary: selected source files, total pages and planned output files. If an image-to-PDF path shares the merge interface, explain whether each image becomes a page or an independent document.
Adobe’s mobile combine-files workflow explicitly includes reviewing and changing file order before combining. The general design lesson is to expose that review before creation. Product-specific subscription, network and storage requirements should not be generalized to every PDF tool.


Preserve the plan until the new artifact is verified.
Store an ordered collection of stable source identities and revisions separately from the destination name. If the user returns from a picker, reconcile the existing collection rather than replacing it with the picker’s current sort order. Deduplicate accidental double selection explicitly, while allowing deliberate repeated insertion only if the product supports it and makes the result visible.
Check unavailable, protected, unsupported and partially downloaded sources before starting. If a source changes after review, ask for another check rather than merging an unseen revision. Preserve original files unless the user separately requests a clearly explained removal. Combining documents should not silently become a cleanup operation.
During creation, prevent duplicate submissions and retain a recoverable plan after interruption. On completion, show the new filename, destination and available preview. Verify the resulting page count and document boundaries with the actual processor. Do not infer preserved signatures, forms, metadata or accessibility from a successful generic merge status.
Check the document, not just the success screen.
Use test sources with visibly different first and last pages. Combine them in the opposite of the library’s sort order, then open the result and check both source boundaries. Repeat with similarly named versions, a protected document, a missing source and an interrupted operation. Confirm that originals remain where the interface promised.
Measure abandoned merges, source replacements, order changes, generation failures and immediate corrections after preview. A user reordering the list is not necessarily struggling; it may be the purpose of the feature. Track whether the final artifact matches the reviewed plan rather than optimizing only the time spent in the selection sheet.
At large text sizes, keep page counts and source identity readable. Screen readers should announce position, file name and the move action. If processing fails, leave the ordered plan and destination available for correction. A recovery route that forces re-selection of every file creates unnecessary opportunities for another ordering mistake.
Review the combine-files contract.
Use these checks on a working build, not only on the polished reference state.
- Separate source count, page total and output count.
- Show and allow revision of the whole-file order.
- Distinguish similarly named source versions.
- Preserve the output name when adding files.
- Retain originals and ordered plans on failure.
- Open the result and verify source boundaries.
Questions and answers
Questions worth resolving before shipping
Is merging PDFs the same as reordering their pages?
No. A merge combines source documents into an output. Reordering pages changes a sequence within a document. A product can support both, but the controls should identify whether a movement affects a whole source or an individual page.
Should selecting files determine their final order?
Only if the rule is clear, visible and editable. A separate order review is safer when people select from searches or differently sorted lists. Do not make an unannounced library sort determine the final artifact.
Can a merge remove the source files automatically?
Not as an unstated side effect. Keep originals unless the product offers a distinct, informed removal decision. A successfully created output does not prove that every original can safely be discarded.
2,805 apps in the top charts.Ask them anything.
Compare real source lists, merge reviews and completed-document flows. ScreensDesign Pro helps you research a PDF tool beyond its primary button.