Reordering, merging and splitting PDF pages
Four operations cover almost every document problem you will ever have. Knowing which one you actually need takes about a minute, and none of it is worth a monthly subscription.
6 min read
On this page
There are only four operations
Almost every PDF problem that ends with someone searching the internet in mild despair is one of four things: pages in the wrong order, several documents that should be one, one document that should be several, or a file that needs numbers on it. That is the whole surface area.
The reason it feels harder than that is the software. Document editors bundle page rearranging with editing, signing, converting and storage, then charge monthly for the bundle, so a five second job arrives wrapped in an account and a trial. The operations themselves are simple, mechanical, and old.
Pick the operation first, then the tool. Getting this order right is most of the battle, because roughly half the time people reach for merge when what they needed was delete, or reach for split when what they needed was reorder.
TL;DR
Wrong order: reorder. Too many files: merge. Too few files: split. Missing numbers: add them last, after everything else is final. Delete unwanted pages before you merge, never after. And keep the original file until you have opened the result and looked at it.
Which operation, and what goes wrong
The table below is the decision, compressed. The gotcha column is the part people learn the expensive way, usually at 11pm the night before something is due.
One structural thing worth knowing: the page tools here take a single file at a time on purpose. Merge is the exception, because combining is inherently a many-to-one job. Everything else works on one document, which keeps the page ranges unambiguous and stops you accidentally rotating the wrong file.
| What you want to do | The operation | The gotcha |
|---|---|---|
| Combine a cover letter, a CV and references | Merge | File order is the order you add them, not alphabetical |
| Pull chapter three out of a 300 page report | Split | Page ranges are inclusive, so 40 to 60 gives you 21 pages |
| Fix a scan that came out in the wrong sequence | Reorder | Do this before numbering, or the numbers follow the old order |
| Remove blank or duplicate pages | Delete pages | Blank does not mean empty: scans often carry faint speckle |
| Add numbering for a submission | Page numbers | Front matter usually should not be counted |
| Correct sideways pages from a scanner | Rotate | Rotation is per page, so check every page, not just the first |
The classic scanner problem
A document scanner without a duplex feeder produces a very specific mess. You scan the whole stack face up, flip it, scan it again, and end up with a file that runs 1, 3, 5, 7 and then 2, 4, 6, 8. Every page is there. None of them are where they should be.
The fix is reordering, and it is less tedious than it looks, because the pattern is fully predictable. For a 20 page document you are interleaving positions 1 to 10 with positions 11 to 20. Do it once, check page 2 is genuinely the back of page 1, and the rest of the sequence is correct by construction.
The second half of that flip introduces the other classic: every alternate page is upside down, because you turned the stack over rather than around. That is a rotation job, 180 degrees on the even pages. Fix rotation before order if both are wrong, because it is far easier to verify the sequence when you can read the pages.
If your scanner produced separate image files rather than a PDF, skip the surgery entirely and build the document correctly from the start with images to PDF, where you control the order as you go.
Check page 2, not page 1
Page 1 looks right in almost every broken scan, which is exactly why people ship them. The first real evidence of an interleaving error appears on page 2, and the first evidence of a rotation error appears on the first page from the second pass.
Delete before you merge, not after
This is the single most useful habit in document work. Clean each source file first, then combine. It sounds like pedantry and it saves genuine time.
The arithmetic is why. Delete a blank page from a 12 page file and you are removing page 12. Merge first, and that same blank page is now page 84 of a 300 page document, sandwiched between two sections you were not looking at. You have to find it, count to it, and confirm you deleted the right one.
So: delete unwanted pages from each file while it is small and while you still remember what is in it. Fix rotation at the same time. Then merge once, into something that is already correct.
The same logic applies to order. Get each component right on its own, then combine them in the order you want the final document to read. Merging usually respects the order you add files rather than their filenames, which is a feature, but it means a file named 01-cover can still end up last if you added it last.
Numbering documents that have front matter
Number last. Numbering is the final step of a document, after every page is present, correct and the right way up, because numbers bake the current sequence into the page content. Reorder afterwards and you get a document that jumps from 7 to 12 to 8.
The convention question is front matter. A cover page, a title page and a contents page are conventionally not counted in the main sequence. Academic and legal work typically numbers front matter separately in lower case roman numerals, then restarts at 1 on the first page of real content.
For everything else, the pragmatic version is simpler: start the visible numbering on the first page of substance and leave the cover unnumbered. If a submission requires that page 1 of the file is labelled page 1, do what the submission says. Institutional rules always beat convention, and they are usually written down somewhere you can check in thirty seconds.
When you add page numbers, position matters more than people expect. Bottom centre is the safe default. Bottom right suits documents that will be printed single sided and stacked. Avoid the top of the page if there is any chance the document will be stapled or hole punched.
Splitting for page limits and separate submissions
Plenty of processes want separate files: a form here, evidence there, each under a stated page limit. This is what splitting is for, and it is worth doing deliberately rather than by trial and error.
Work out the boundaries before you start. Read the requirement, write down the ranges you need, then split once. Page ranges are inclusive at both ends, which is the most common off by one error in the entire field: pages 1 to 10 is ten pages, and if the limit is ten then 1 to 11 is a rejection.
If a file needs to be signed, split it first. Signatures are applied to a finished document, and rearranging pages afterwards can invalidate a signature or, at best, leave you explaining why the signed version differs from the submitted one. Sign last, exactly as you number last.
If someone needs to read the text but not receive the document itself, PDF to text or PDF to JPG gives you a page image or plain text without shipping the original file and everything attached to it.
The one warning that matters
All of these operations rewrite the file. They are not edits layered on top of the original: the result is a new document, and the old one is not inside it. Keep the source file until you have opened the output and actually looked at it.
Not skimmed the thumbnails. Opened it. Check the first page, the last page, the total page count against what you expected, and any page where two source documents meet. Ninety seconds of checking catches essentially every mistake described above.
Bookmarks, form fields and existing annotations are the things most likely to be simplified or lost when a document is rebuilt. For a plain report that is irrelevant. For an interactive form or a heavily commented draft it matters, so verify those specifically rather than assuming.
Then throw nothing away for a week. Storage is free and re-scanning a 40 page contract is not.
Tools from this guide
Keep reading
Why is your PDF 40MB when it looks like plain text?
A twelve-page letter should weigh about as much as an email. When it weighs forty megabytes, the pages are almost certainly photographs rather than words.
Which image format should you actually use?
JPEG, PNG, WebP, AVIF, SVG. Five formats, endless arguing, and a decision that usually takes ten seconds once you know what the question really is.
Why your CSV opens wrong, and how to stop it
A file of plain text separated by commas should be the simplest thing in computing. Instead it eats your leading zeros, turns product codes into dates, and opens as one column for half your colleagues.