Merge PDFs
Combines the parts of a finished package into a single deliverable PDF, in the sequence fixed for that package type.
Overview
Most finished paperwork isn't one form. An appraisal report is a main form plus photo pages plus a sketch plus a location map plus a signed engagement letter. An insurance submission is an application plus certificates plus schedules. Each piece is produced separately, and then somebody has to put them together in the right order and send one file.
Merging is the step where that happens. Once no part of the package is still filling, the parts are concatenated into one document, each keeping its own page size, orientation and embedded fonts. A landscape page stays landscape; a legal-size page stays legal-size.
Order matters more than it sounds. Reviewers and submission portals often expect a specific sequence, and a package assembled in the wrong order gets bounced. Every part carries the position it occupies in the package, and the merge follows those positions — not the order files were uploaded, and not the order parts finished filling.
What It Does
| Capability | What it means for you |
|---|---|
| Ordered assembly | Parts land in the positions recorded for them, not upload order or completion order |
| Mixed page geometry | Portrait, landscape, letter, legal and custom sizes coexist in one file without being stretched or cropped |
| Nothing re-rendered | Text stays selectable and searchable, vector line work stays sharp, and images are not re-compressed |
| Skips empty parts | A part with nothing in it is left out instead of contributing blank pages — unless it is one of the parts that always appears, and even those are left out when their job is to carry an image and none was assigned |
| Blank stands in for unfilled | A part that belongs in the package but has no filled version goes in as its blank version, so the gap is visible rather than missing |
| Single output | One file to download, email or upload, instead of a folder the recipient has to reassemble |
When This Runs
Nothing chooses this step. It runs at the end of every package run, once no part is still filling, and it runs the same way for every workflow — appraisal reports, pre-bid submissions and coating QA packets alike.
What goes in is settled before the merge by rules fixed for the package type, not decided per run. A part with nothing in it is left out, so a package whose photo addendum was never populated produces a shorter document rather than one padded with empty pages. Parts that always belong in the deliverable go in whether or not they hold any data — with one rule that overrides even that: a part whose place in the package is to carry an image is left out when no image has been assigned to it, always-included or not.
A part that belongs in the package but has no filled version goes in as its blank version. A visible empty form tells a reviewer exactly what needs attention, while a silently dropped section looks like the package is complete when it isn't. If no blank version is on file for that part, it is left out and counted among the parts skipped.
Merging is not the last step. Images assigned to slots are stamped onto the merged document afterwards, then pages pulled from a source document are dropped into it — see Insert Source Pages — and headers and page numbers go on last.
Inputs and Outputs
Takes: the parts of a package that qualified for inclusion, each in its recorded position.
Returns: one PDF, with counts of the parts that went in, the parts that came from a blank rather than a filled version, and the parts left out.
Nothing is re-rendered during the merge. The pages that go in are the pages that come out, which is what keeps text searchable.
Example
An appraisal package holds a main report form, a photo addendum, a building sketch and scanned exhibits — among them a location map.
Each part is produced separately. At merge time they are concatenated in the sequence fixed for that package type: report first, then the photo addendum, then the sketch, then the scanned exhibits. A part that always belongs in the deliverable goes in at its position even when it holds no data — unless its place in the package is to carry an image and none was assigned, in which case it is left out anyway.
Had no location map been uploaded, no location map part would exist, and the merged document would simply be one part shorter rather than one blank page longer.
The result is a single file the appraiser downloads and sends.
Limits
- Merging preserves what it's given. It does not re-order pages inside an individual part, resize pages to a uniform paper size, or re-compress images.
- The merged file is a finished document rather than a form. Values that were filled in stay visible on the page, but the combined file does not open as a fillable form the way each separate part did.
- Merging compresses nothing, so a package of large scans produces a large file. Rasterizing pages is the lever when output size matters more than text selectability.
FAQ
Does merging change the quality of the original pages?
No. Pages are carried across as they are, so text stays selectable, vector line work stays sharp and images are not re-compressed.
What happens if one part of the package failed to fill?
Its blank version is included instead of being dropped. A visible empty section makes the gap obvious to whoever reviews the package, which is safer than a document that looks finished but is missing a form. If no blank version is on file for that part, the part is left out and counted among the parts skipped.
Can pages of different sizes and orientations be combined?
Yes. Each page keeps its own dimensions and rotation, so a landscape sketch or a legal-size addendum sits alongside letter-size forms without distortion.
Can I control the order of the merged document?
The sequence comes from the position recorded for each part, so it is the same on every run. It does not depend on the order files were uploaded or the order parts finished filling.
Is this the same as a free online PDF merger?
The operation is similar; the context is not. This runs as one step at the end of a run that has already filled each part of the package. You aren't picking files by hand — the merge happens automatically as part of producing the finished document.