Computers sort text one character at a time, so page10 comes before page2 because 1 comes before 2. Any batch that runs past nine files will scramble.
Three fixes, in order of durability: pad the numbers in your filenames, drag the files into position before merging, or rebuild the order from the merged file with a range selection.
You merged twelve files and got a document that runs 1, 10, 11, 12, 2, 3, 4. Nothing is missing, nothing is corrupted, and the sequence is useless. It looks like a bug and it is not one.
Why page10 comes before page2
Sorting text is not the same as sorting numbers. When a computer compares two filenames it goes character by character, left to right, and stops at the first difference.
Comparing page10.pdf with page2.pdf, the first four characters match. At the fifth, it compares 1 against 2. One sorts before two, so the comparison ends there and page10 wins. The fact that ten is larger than two never enters into it, because nothing in that comparison is treating them as numbers.
page1.pdf1stpage10.pdf2ndpage11.pdf3rdpage2.pdf4thpage20.pdf5thpage3.pdf6th
Three ways to fix it
All three work. They differ in how much they protect you next time.
Pad the numbers
Rename the files so every number has the same number of digits. page01.pdf through page12.pdf sort correctly under plain alphabetical rules, because now the comparison at the fifth character is 0 against 1, which gives the answer you wanted.
This is the only fix that travels. The order is baked into the names, so it survives being emailed to a colleague, uploaded to a different tool, or opened on another operating system. If you merge batches regularly, this is the habit worth building.
Arrange them by hand
Merge tools that show the loaded files as a list let you drag them into place before combining. Load everything, arrange deliberately, then merge. This is the fastest fix for a one-off job and it requires no renaming at all.
The catch is that it protects only this merge. Do the same batch next month and you will be dragging again.
Rebuild the order afterwards
If the merge has already happened and re-running it is awkward, the range field can reorder the finished document. Selections keep the order you type them, so extracting 1,5,6,7,8,9,10,11,12,2,3,4 from the scrambled file produces a correctly ordered one.
Work out the mapping by opening the merged file and writing down where each page actually landed. Tedious for twelve files and genuinely useful when re-merging is not an option.
Fix it once, permanently
- Correct order in every tool, on every system
- Survives being shared with other people
- No dragging, no manual step at merge time
- Works for scanner output if you set the pattern
- Takes one rename pass to set up
Fix it for this job only
- No renaming, immediate result
- Fine for a batch you will never repeat
- Has to be redone every single time
- Easy to misplace one file in a long list
- Does not help anyone else you send the files to
When the scanner caused it
Scanner software is a frequent source of this, because it names files by an internal counter that has no relationship to the order you fed the paper in. Sheet feeders that split a batch across several files are worse, since the split points are decided by the hardware.
If the scanner lets you define a filename pattern, set one with padded numbering and the problem disappears at source. If it does not, one rename pass after scanning and before merging is the cheapest place to intervene.
When the whole document is backwards
A completely reversed order is a different problem with a different cause. Usually the scanner fed the stack face-down, or the software was set to add each new page at the front rather than the back.
The range field handles it: type the page numbers in descending order and extract. For a twelve page document, 12,11,10,9,8,7,6,5,4,3,2,1 gives you the document the right way round. Worth checking the scanner setting afterwards so it does not happen on the next batch.
Merge with drag-to-reorder
Arrange the files exactly as you want them before combining. Nothing uploaded, nothing tracked.
Common questions
The follow-up questions once the cause makes sense.
01Why does my merge tool ignore the order in my folder?
Because your file manager and the merge tool sort differently. Windows Explorer and macOS Finder use natural sorting, which reads runs of digits as numbers. Most other software sorts plainly, character by character, which puts page10 before page2.
02What is the most reliable way to control merge order?
Pad the numbers in the filenames so they are all the same length: 01 through 12 rather than 1 through 12. That makes plain alphabetical sorting produce the order you want, and it keeps working in every other tool and on every other machine.
03Can I fix the order without merging again?
Yes. Open the merged file, note where each page actually landed, and extract a range listing the pages in the order you want. Range selections preserve the sequence you type, so the output comes out correctly ordered.
04My entire document is backwards. Why?
Usually the scanner fed the stack face-down, or its software inserted each new page at the front instead of the back. Extract a descending range to reverse it, then check the scanner setting so the next batch comes out right.
05Does reordering pages reduce quality?
No. Reordering copies page objects into a new sequence without re-rendering anything. The pages are byte-identical to what they were, just listed in a different order in the page tree.
06Why did only part of my document scramble?
Because the batch crossed from single to double digit numbering. Files 1 through 9 sort correctly among themselves, and 10 onwards insert themselves after 1. If your batch had nine or fewer files you would never have seen the problem.