How to combine scans into one PDF file

Scan as one file: assembling a pile into a single PDF

"Send the scan as one file" is a short request, and what the scanner actually produces is usually not that. One person gets twenty separate one-page PDFs, another a folder of JPEGs, a third both mixed together. Assembling it is not hard, but a couple of steps happen in a different order than the intuitive one.

What "one file" really asks for

The requirement almost always means three things at once, and the second and third get checked by a machine.

First: one file instead of a pile, because the person on the other side is not going to sort your attachments. Second: pages in the order they lay on the desk. Third, often: a text layer, so the document can be found by search in their system.

That third requirement is rarely stated out loud, and people remember it once the package has already bounced. Checking is easy: open your file and try to select a line of text. If the whole page highlights as a picture, there is no text layer.

What your scanner handed you and what to do about it

That last row is the most common and the most awkward. Merging accepts PDFs only: slipping a photograph straight into it will not work, the file fails the type check. The order here is rigid: jpg-to-pdf turns the shots into a single PDF first, and only then does that PDF go into merge-pdf alongside the other parts.

How to assemble the package

1. Bring everything to PDF: photos become their own file through jpg-to-pdf. 2. Open merge-pdf and upload every part at once. 3. Choose the merge order: keep the upload order, or sort by name. 4. Check the list: a position number sits to the left of each name and shows the coming sequence. 5. Run the merge and download the finished file. 6. Page through the result, paying attention to the first and last pages of each part.

File names decide more than you would think

Sorting by name here is not plain character comparison. Names are parsed with numbers in mind: `scan_2.pdf` lands before `scan_10.pdf` rather than after it, which is what ordinary alphabetical sorting would do. That is precisely the case the sorting was built for, because scanners almost always number files without leading zeros.

A practical conclusion follows. If the scanner named the files `img001`, `img002` and onward in sequence, sorting by name assembles the package correctly with no help from you. If the names are heterogeneous, something like `contract`, `annex`, `certificate`, sorting by name puts them in alphabetical order, which almost certainly is not the order you need. In that case keep the upload order and arrange the files by hand.

Arranging by hand works two ways. On a computer you drag a file with the mouse. On a phone dragging will not work and you need the up and down arrows next to the name: the list uses the plain drag-and-drop mechanism, and that does not respond to a finger.

There is a third sorting option, by size, smallest first. For scans it is useless: a page weighs what the ink on it weighs, which has nothing to do with where it belongs in the document.

One broken file stops the whole merge

Scanners and office machines regularly emit PDFs with damaged internal structure: the file opens in one program and refuses in another. The service anticipates that and makes one attempt to repair the structure itself before giving up.

If the attempt fails, the job stops outright, and the message carries the name of the specific file, the name you uploaded it under rather than an internal identifier. That speeds up the diagnosis considerably: you know which sheet to rescan or what to fix. A dedicated pass through repair-pdf digs deeper than the automatic attempt made during a merge.

A separate check runs at upload time. A file that did not transfer completely is rejected before any processing: a correct PDF carries an end-of-file marker, and its absence means the transfer was cut short. This tends to happen when uploading from cloud folders where the file has not synced locally yet. The cure is uploading again once the file has genuinely landed on the device.

An empty PDF with no pages will also stop the merge, again by name. Such files sometimes survive a failed scan and look no different from healthy ones.

A separator sheet between documents

The merge parameters carry a switch that inserts a blank sheet between every two documents. For a package of several standalone documents that is handy: in print and while paging, you can see where one ends and the next begins.

One detail: the separator takes its size from the preceding page. If the parts of the package use different formats, the separator repeats the format of the part it follows. On uniform scans nobody notices; on a mix of A4 and phone shots it looks odd.

A scan always weighs more than you expect

Twenty pages out of an office scanner in colour is comfortably 30 to 60 MB, and phone photos give you more. The merge compresses nothing: it stacks pages as they are, so the final weight is the sum of the parts.

Compress after merging, not before: compress-pdf will process the whole package in one pass, which is both faster and more predictable than squeezing each part separately.

If blank backs from duplex scanning ended up inside the package, drop them with remove-blank-pages: every such sheet takes space and adds to the printing bill.

Two last checks before sending

Rotation. A sheet feeder occasionally flips individual sheets, and in the assembled file they sit upside down. Tick only those pages in rotate-pdf and turn them: rotation applies to the sheets you select, not to the whole document.

The text layer. If the receiving side searches across documents, run the finished file through ocr-pdf. Recognition lays an invisible text layer over the image, and the picture of the page itself does not change.

The order of those two operations matters more than it looks. Recognition works from the page image, and compression degrades exactly that image: it lowers the resolution and adds artefacts around the letters. So recognise before compressing, not after. The reverse order produces noticeably more errors in the recognised text, especially in small type and on stamps, and there is nothing left to fix them with afterwards.

An assembled, rotated, recognised and compressed package is the "one file" that was asked for. Check it in the same kind of program the recipient will open it in: a browser viewer and a desktop reader treat page rotation differently, and it is better to see the discrepancy on your own screen.