Tools · PDF · Rotate PDF · Guides · Fixing a Scan That Mixes Portrait and Landscape Pages
Fixing a Scan That Mixes Portrait and Landscape Pages
A document that genuinely mixes orientations - most pages upright, a few sideways from a scan issue, or a deliberately landscape page (a wide table, a diagram, a certificate) sitting inside an otherwise-portrait report - needs a page-by-page approach, not a single whole-document fix. Here's how to sort one out efficiently rather than clicking through every page individually.
Two different problems that look similar
It's worth telling these apart before you start, since they need different fixes. The first: a scan or photograph captured some pages at the wrong angle by accident - these are "wrong" and should be rotated to match the rest. The second: a page is intentionally landscape because its content genuinely reads better that way - a wide table, a diagram spanning the page's full width - and rotating it to match the surrounding portrait pages would actually make it harder to read, not easier. The fix for the first is "rotate it to match." The fix for the second is "leave it exactly as it is." Getting these two categories mixed up - rotating a genuinely landscape table just because it's the odd one out visually - makes the document worse, not better.
Sort by orientation, fix only what's actually wrong
The efficient workflow
Load the document into the PDF rotate tool and scan the whole thumbnail grid first, before clicking anything - this gives you the full picture of which pages are actually wrong versus intentionally different, rather than fixing pages one at a time as you scroll and potentially mis-judging an intentional landscape page along the way. Once you've identified the genuinely wrong pages, rotate each one individually using its own rotate-left or rotate-right button, leaving any deliberately landscape pages completely untouched.
When most of the document is wrong the same way
If the majority of pages share the same accidental rotation - a whole scanning session that came out 90 degrees off, say, with just a couple of pages that were fine - the faster path is "Rotate all pages" once in the needed direction, which corrects the majority, and then individually correcting (rotating back, or in the other direction) the handful of pages that were already fine and just got rotated the wrong way by the all-pages click. This is often faster than clicking through dozens of individually-wrong pages one at a time, even though it means one or two pages need a second, corrective click afterward.
What to do about a page you're genuinely unsure about
A borderline case comes up often enough to name: a page that's landscape and you're not sure whether it was intentional or accidental, especially in a scanned packet with no context about how it was originally captured. The safest default is to leave it as-is rather than guess wrong - a table or figure that's genuinely meant to be landscape looks obviously broken if forced to portrait (text running the wrong way, content spilling off the visible page), while a genuinely accidental sideways page in the middle of a text-heavy report is usually easy to identify by the text itself simply not being readable at its current angle. If a page's content reads fine at its current orientation, it's very likely intentional; if it clearly doesn't, it's very likely accidental.
A mixed batch doesn't need to be split into separate files
It's tempting to think a mixed-orientation document needs to be split into a "portrait section" and a "landscape section" processed separately, but that's not necessary here - both the whole-document and per-page rotate controls work on the same loaded file at the same time, so a document with three genuinely different orientation groups (mostly portrait, a few accidentally sideways, one intentionally landscape) can be sorted out in a single pass without splitting anything apart first.
Confirming the result before you commit
Because every thumbnail reflects its pending rotation live as a CSS-level preview - the actual PDF content isn't touched until you click Rotate - it's worth doing a final scan across the whole grid once you think you're done, confirming every page that should be upright actually looks upright and every intentionally-landscape page is still in its original orientation, before committing to the save.
What the rotation costs, regardless of how many pages are involved
It's worth knowing that fixing three pages or fifteen pages in a mixed batch costs roughly the same amount of processing either way - a page's orientation is a single stored value, not something that requires re-rendering the page's actual content, so the save step at the end is cheap regardless of how many individual pages you've adjusted. The only real cost that scales with the document is the initial thumbnail rendering, which shows a progress line past 50 pages so a genuinely long mixed document doesn't leave you staring at a blank screen wondering if anything's happening.
For the mechanics of fixing a single page specifically, see how to rotate just one page. And for the common causes behind a scan coming out mixed in the first place, see why scanned PDFs come out sideways.