Putting a Scanned Document Back in the Order It Was Printed

Reordering and extracting are the same machine, aimed differently

Both operations do the same thing under the surface: make an empty document, copy pages into it, save. Extraction hands that machine a short list — pages four and five — and the result is a two-page file. Reordering hands it a permutation of every page, and the result is a complete document in a different sequence. Deleting a page is reordering with one index left out; inserting one is a merge followed by a reorder. There is no separate mechanism for any of them, which is why they behave identically in the ways that matter.

The duplex interleave, and why dragging pages is the slow way

A scanner without a duplex feeder asks you to scan one side of the stack, turn it over, and scan the other. The output is not shuffled — it is two runs joined end to end. For a ten-sheet document you get pages 1, 3, 5, 7, 9, 11, 13, 15, 17, 19 followed by their backs, and where those backs land depends on how you turned the stack: keeping the order gives 2, 4, 6 … and flipping the whole pile gives 20, 18, 16 … in reverse. Recognising which of the two you have takes one glance at the last page of the file, and it tells you the entire permutation without inspecting anything else.

That is why writing the sequence out beats dragging thumbnails. Dragging is a page-at-a-time operation on a problem that has a closed form: you already know where every page goes, and stating the order once is both faster and impossible to get half right. On a twenty-page document, dragging is nineteen chances to drop something in the wrong place; a written sequence is one thing to check before you press the button.

What does not survive the rebuild

Pages carry their own content, so text, images, page size and rotation all come across exactly as they were. What is attached to the document rather than to a page is where the losses are. Bookmarks point at page objects and are commonly dropped or left pointing somewhere unhelpful. Internal links between pages break for the same reason. Form fields usually survive individually but their document-level structure can be rebuilt in a way that changes behaviour, which is why flattening a completed form before reordering is the safe habit. Attachments and document-level metadata may or may not be carried. And a digital signature is invalidated, without exception, because it describes a byte sequence that no longer exists.

Duplicates, blanks and the page that came out twice

A duplex scan of single-sided sheets produces a blank page after every real one, which doubles the file and irritates every reader. Removing them is reordering with the even indices left out, and it is worth doing before anything else because it halves the number of pages you then have to think about. Be careful with what counts as blank: the back of a printed sheet often carries faint show-through or a printer's registration marks, so check rather than assume a page is empty because it looks pale in a thumbnail.

The last check is the same one that closes every operation in this batch: count. The result should have exactly the number of pages you intended, which for a pure reorder is the number you started with and for a blank-removal is half of it. A count that is one out is a page you dropped or kept by accident, and it is far cheaper to find now than in the reply from whoever you sent it to.

Frequently asked questions

Is reordering lossless?

For the page content, entirely. Copying a page moves its drawing instructions and its embedded images across as they are, with no decoding and no re-encoding, so a scan reordered ten times is bit-for-bit the same scan. The losses, where they exist, are structural: bookmarks, internal links, form structure, attachments and any signature. A scanned document has none of those, which is why this is the safest operation in the whole set on exactly the files people most often need it for.

How is this different from extracting pages?

In what you keep, not in how it works. Extraction produces a shorter document containing only the pages you named, which is what you want when a form asks for proof of address and you have a six-page bill. Reordering produces a complete document in a different sequence, which is what you want when the whole thing has to be readable from start to finish. Mechanically both build a new file page by page, so the same things survive and the same things do not.

Can I insert a page into the middle?

Yes, in two steps: merge the new page onto the end of the document, then reorder so it lands where it belongs. It feels roundabout and it is exactly what any tool offering an insert does internally, because there is no operation that puts a page into a sequence without rewriting the sequence. Doing it explicitly has one advantage — you state the final order once and can check it before pressing the button, rather than trusting a drag to have landed on the right boundary.

My document has bookmarks. Will I lose them?

Probably, and if they matter you should plan for it rather than discover it. Bookmarks are a document-level tree pointing at page objects; rebuilding the document creates new page objects, and most tools do not rewire the tree to match. On a scan it is a non-issue. On a long report with a navigable table of contents, do the reordering first and rebuild the bookmarks afterwards on the finished file, or fix the order in whatever produced the document rather than in the PDF.

The scan has a page upside down as well as out of order. One operation or two?

Two, and the order between them does not matter because they touch different things: rotation writes a property on a page, reordering rebuilds the sequence of pages, and a page carries its rotation with it wherever it lands. Do whichever is easier to see first — usually rotation, because an upside-down page is obvious in a thumbnail strip and a wrong sequence is not.