Merging an Application Pack into One PDF, in the Right Order

The ordering bug is in the sort, not in you

Almost every merge that comes back rejected comes back for the same reason, and it is not carelessness. File names are text, and text sorts character by character: "1" comes before "2", so "10-payslip" comes before "2-payslip", because the comparison stops at the first character and never reaches the rest. A folder holding eleven documents named 1 to 11 presents itself as 1, 10, 11, 2, 3, 4 … and a merge tool that respects the order it was given will faithfully produce a document in exactly that sequence.

Some file managers hide this with natural sorting, which reads runs of digits as numbers and puts 2 before 10. That is helpful on screen and treacherous in practice, because the helpfulness is not portable: the same folder ordered one way in your file manager arrives ordered the other way in a web upload dialog, a command line or a colleague's machine. Two-digit prefixes are immune to the difference — 02 sorts before 10 under both rules — and cost nothing. Use three digits past a hundred files, for the same reason.

Page size is stored per page, and that surprises people

A PDF does not have a size; each of its pages does. Merging therefore never resizes anything — it copies pages across with their dimensions intact, which is exactly the behaviour you want when the pages are evidence and exactly the behaviour that produces an ugly result when they are not. A pack containing an A4 contract, a passport photographed at 4:3, a bank statement exported at US Letter and a landscape spreadsheet is four different papers bound together, and it will print as four different papers.

Whether to fix it depends on the reader. A system that ingests the file and displays it on screen does not care, and normalising costs you nothing but also gains you nothing. A person who prints the pack to read it does care, and so does anyone who has to file the printed copy. When you do normalise, scale rather than crop: cropping a scanned identity document to fit A4 can cut a corner off a stamp, and a document with a missing corner gets sent back.

Merging destroys a digital signature, always

This one costs people real time, because the failure is silent. A digital signature is a cryptographic statement about a specific sequence of bytes: this exact file, unchanged since I signed it. Merging produces a new file with a new byte sequence, so the statement no longer matches anything, and the signature is not carried over — it is invalidated or dropped. The merged pack opens perfectly and looks right. It simply is no longer signed, and the first person to check will say so.

There are two workable answers and one that is not. The workable ones: send signed documents as separate attachments alongside the merged pack, which is what most procedures expect anyway; or merge everything unsigned and apply a signature to the finished pack, which is stronger because it then covers the whole submission. The one that does not work is merging and hoping — a signature cannot be reattached to a document it does not describe. If you are unsure whether a file is signed, open it and look for a signature panel before you plan the merge, not after.

Encrypted files stop the merge before it starts

Banks and payroll systems routinely send statements as password-protected PDFs, often with a password derived from a date of birth or a customer number. A merge tool cannot read the page structure of an encrypted file, so it cannot copy pages out of it, and it will refuse rather than produce a broken result. Remove the protection with the password you already have, merge, and then decide whether the finished pack needs protecting again — for a document about to be uploaded to a portal over an encrypted connection, usually it does not.

Photographs of documents need converting first

Half of any modern application pack arrives as phone photographs: an identity card, a utility bill, a handwritten note. Those are images, not pages, and a merge tool that expects PDFs cannot place them. Convert them to PDF first and they become ordinary pages that merge in sequence with everything else. Doing the conversion deliberately is also the moment to fix the things that get documents rejected — a photograph taken at an angle, a shadow across the text, a resolution far higher than anyone needs.

The two-second check that catches the expensive mistake

Add up the page counts of the parts before merging and compare with the total afterwards. If they match, nothing was silently dropped; if they do not, a file failed to load and the tool told you in a message you scrolled past. Then open the result and check the first page of each section. Both checks together take less time than reading this paragraph, and they catch the two failures that actually cost you a week: a missing document, and a pack in the wrong order that the recipient reads as carelessness.

Frequently asked questions

The pages came out in the wrong order. Can I fix it without starting again?

Yes — reordering pages in the merged file is a separate operation and works fine, and for a handful of misplaced pages it is quicker than redoing the merge. But if the whole pack is scrambled, renaming the sources with two-digit prefixes and merging again is faster and less error-prone than dragging thirty pages into place, and it leaves you with a folder that will merge correctly the next time you need to add a document.

Is there a limit to how many files I can merge at once?

Not a fixed one — the constraint is your device's memory, because the whole result is assembled there before it is saved. On a laptop, a pack of a few dozen ordinary documents is unremarkable. Where you can run into trouble is hundreds of pages of high-resolution scans on a phone, which may make the browser reclaim the tab. If that happens, merge in two halves and then merge the halves, which keeps peak memory to roughly half.

Should I merge everything, or send separate files?

Do what the requester asked, because the instruction usually reflects how their system ingests it. When they have not said, one merged pack in their stated order is the safer default for a human reviewer, and separate named files are safer where a system matches each document to a checklist item. Two exceptions override both: signed documents go separately so their signature survives, and anything that would push the pack over an attachment limit is better split than degraded.

One of my files did not appear in the result. Why silently?

It is rarely truly silent — the message usually appeared and scrolled away, or the file was skipped at load time before you pressed the button. The usual causes are a file that is not really a PDF despite its extension, a corrupted download that never finished, or an encrypted file. This is exactly what the page-count check catches: if the parts add to 47 pages and the result has 39, one document is missing and you know before the recipient does.

Does merging reduce quality?

No. A merge copies page objects from one document into another without decoding or re-encoding anything, so text stays text and an image inside a page comes across as the same image. The result is the sum of the parts in size as well as in pages, give or take a small structural saving from shared resources. If you need it smaller afterwards, compress the merged file as a separate step rather than looking for a merge setting that does not exist.