← All posts

Scan both sides on a single-sided scanner

You have a stack of paper printed on both sides and a scanner that photographs one side at a time. The obvious move is to feed the pile through, turn it over, feed it through again. That part nobody needs telling.

What nobody writes down is which way to turn the pile, what the second file will look like when you open it, and how the two halves go back together into a document that reads 1, 2, 3, 4. The vendor support pages describe the buttons on one particular machine. The forum threads are people asking which software to buy.

The method is the same on every scanner, because the scanner is not the variable. Here it is.

The scanner does the same thing twice, so the paper decides everything

Your feeder has a rule — sheets go in face up, or face down, and it pulls from the top of the pile or the bottom. Whatever that rule is, it applies identically to both passes. It therefore cancels out, which is why you do not need to know it, and why advice written for one model works on all of them.

The only thing that changes between pass one and pass two is what your hands did to the paper. There are three possibilities and each one produces a different second file.

You turned the whole pile over about its long edge — the way you turn a page in a book, so the spine side stays the spine side. Flipping a block reverses it: the sheet that was on the bottom is now on top. So the backs are scanned last sheet first. The pages are the right way up, and the file runs backwards.

You turned the whole pile end over end, about the short edge. Same reversal, plus every back is now upside down, because the top edge of the paper is where the bottom edge used to be. Backwards and rotated 180°.

You turned each sheet individually and put it back on the pile in the same place. No reversal: the backs come out in order, 1, 2, 3. Correct, upright, and roughly two hundred chances to get distracted halfway down a stack of two hundred.

Pick the first one. It is a single movement and the reversal it causes is undone by one tick later. The end-over-end flip is not unfixable, it just needs an extra step that nobody remembers taking when the document turns up wrong a week later.

At the machine

  1. One file per pass, not one file per page. In the scan software, set the output to a multi-page PDF. If your scanner insists on writing one file per sheet, that is fine — you will join each batch with Merge PDF first, but name them so they sort properly, because page10 sorts before page2.
  2. Turn off blank page removal, and turn off automatic page rotation. See the warning below. These two settings are the reason most two-pass scans come out misaligned.
  3. 300 dpi, greyscale, for ordinary printed text. 200 is enough to read and not enough to recognise reliably later; colour triples the size of a page that has no colour on it.
  4. Feed the pile, keep it square, do not tidy it between passes. Take the output stack out, turn it over as one block, put it straight back in.
  5. Scan the backs into a second file. Before you leave the machine, check both files have the same number of pages. Our PDF inspector reads a page count in the browser without uploading anything, if opening two PDFs is more effort than it sounds.

Putting the two files back together

The tool is not merge. Merge concatenates, so it hands back the whole of the fronts and then the whole of the backs; the operation that alternates between the two files is Alternate & Mix PDF, and why the two get confused, and the order to add the files in is written out step by step there. Two things about it are particular to a two-pass scan.

  1. If you flipped end over end, deal with the rotation first: run the backs file through Rotate PDF at 180°, every page. Doing it now means one job on one file. Doing it after the mix means naming even on a document where the parity has to be exactly right.
  2. Tick "the second file is back to front" if you flipped the pile as a block, either way up. That tick is the block reversal described above, undone. Leave it off if you flipped sheet by sheet, because nothing was reversed.

Then read the result while the paper is still on your desk: the first four pages, and the last four, which is where a mismatch in the two page counts shows itself. Re-feeding a pass now costs five minutes; noticing next week costs finding the stack again.

The odd sheet, and the last blank back

The awkward arithmetic is at the end of the stack, and it is worth knowing which case you are in before you start deleting things.

If every back was scanned, including the blank one on the final single-sided sheet, both files have the same number of pages and the interleave is exact. You are left with one blank page at the end of the document. Delete it by number with Delete PDF pages.

If the backs file is one page shorter than the fronts file, the missing image is harmless in exactly one situation: when it is the last sheet's back. Flip the pile as a block and that sheet arrives at the scanner first, so a dropped blank there costs you the first image of the second pass — which the reverse tick reads as the last one, and the run lands correctly with a lone front at the end. Any other gap shifts every pair after it. If the two files differ by more than one page, a sheet was double-fed, and no tool can invent the side of paper that never went past the sensor.

If the whole stack was single-sided and every second page is now blank, do not list them one by one: even in Delete PDF pages takes all of them in a pass. That pattern holds only while the parity does, and a scanned blank page is never numerically blank, which is why finding them is harder than deleting them.

When the tick is not enough

Only the second file can be reversed. Up to ten files can take part in a mix — fronts, backs and a set of inserts, say — but if the reversed one is not in second place, reverse it beforehand instead: Organize PDF pages takes a run written high to low, so 120-1 on a 120-page file hands it back backwards. Then mix in whatever order you like.

It is also the repair route if you have already interleaved something wrongly and deleted the two source files, which means writing the whole page order out by hand. Far better not to delete them until the result has been read.

What our tools will not do here

Nothing is straightened or cleaned. Pages are copied across as they are. A sheet-fed scan is usually a degree or two out, and Deskew PDF will level it — at a price that matters if the file has been recognised already, because a corrected page is redrawn as an image.

Nothing becomes searchable. Our OCR PDF reports which pages carry real text and which are pictures; it cannot add a text layer, because Tesseract is not installed here. For a scan that has to be searchable, use OCRmyPDF or your scanner's own recognition setting.

The result is a new document, so bookmarks and form field definitions from the two sources are left behind. On a scan there are none of either.

Better: never make two files

If this is a job you do more than once, do the reassembly in the scanning software and skip the whole business.

The paid app the search results keep pointing at does the same thing. You do not need it.

If you are photographing the sheets with a phone rather than feeding them, the same pairing applies — and JPG to PDF reads each photo's EXIF orientation, so a sheet shot sideways comes out the right way up rather than needing a rotation you did not expect.

And if you are here after the fact, with an odd-pages file and an even-pages file already sitting on your desktop, the command-line versions of the interleave — pdftk shuffle and qpdf --collate — are written out in full here.

Tools this post uses: