A scanned PDF looks correctly oriented in one viewer and lies on its side in another. Or you rotate it, save it, send it — and it arrives back in the original orientation. These mismatches come from the fact that a PDF stores the page content and a separate instruction saying how far to turn it before display.
Normalisation collapses that separation. The rotation instruction attached to each page is baked into the page content itself and then cleared, so the orientation you see becomes the orientation that actually exists — in every application, through every subsequent operation. All of it runs in your browser.
The rotation flag, and what goes wrong with it
What you see is not what is stored
Each page in a PDF can carry an instruction, separate from its content, saying something like "turn this 90 degrees before displaying it". Scanners add it when they detect paper orientation; viewers add it when you rotate and save. A viewer honours it, so what you see on screen is correct.
Trouble starts the moment the file reaches something that ignores that instruction, or interprets it differently. The content itself was never rotated, so ignoring the flag means handling the page sideways. That is exactly why the same PDF appears in different orientations in different applications.
Coordinates drift in editing tools
The clearest practical damage shows up when you draw on a page. Placing a redaction box or a stamp, the position shown on screen and the position in the PDF's internal coordinate space differ by the rotation — so what gets covered is not what you covered.
After normalisation the on-screen position and the internal coordinates agree, and the drift disappears. Using it as a preparation step before markup is this tool's most practical role.
What happens inside
A transformation matrix is prepended into the content
A single transformation matrix with the same effect as the rotation is inserted at the front of the page's drawing instructions — 90 degrees' worth for a 90-degree page, and so on — rotating the coordinate system itself. The existing instructions are wrapped in a graphics-state save and restore so they fall inside that transformation. The page dimensions are then updated to the rotated width and height, and finally the rotation flag is set back to zero.
In other words, an external annotation saying "turn this before displaying it" is replaced by content that is already drawn turned. The visual result is unchanged, but it no longer depends on anyone honouring the flag.
Nothing is rasterised, so nothing degrades
The key property is that pages are not redrawn as images. Text stays text, vector graphics stay vectors, embedded images stay as they were. Text therefore remains selectable and searchable, edges stay crisp at any zoom, and embedded fonts are untouched.
The size impact is negligible too: what gets added is one transformation and a save/restore pair, on the order of a few dozen bytes per page. The side effects of image-based approaches — a file that balloons several times over, text you can no longer select — do not occur.
Only pages that carry a rotation flag are touched; pages already at zero are left alone. After processing you are told how many pages were normalised and how many were left as they were.
Text content is no longer a constraint
An earlier approach redrew pages as images, which meant pages containing text had to be excluded to avoid degrading them. The current implementation manipulates the structure directly, so that restriction is gone: text-heavy pages, image-only pages, and rotations of 90, 180, or 270 degrees are all handled identically.
Scope
This is not a tool for changing orientation
Normalisation does not change how the page looks. It makes the current appearance into the reality. If a PDF genuinely appears sideways and you want it upright, rotate it first with the page organiser and then normalise, or simply save the rotated result.
So the problem this solves is not "the orientation is wrong" but "the orientation looks right and other tools disagree". Confusing the two leads to unexpected results.
Only quarter-turn rotations are handled
What is handled are the quarter-turn rotation values the PDF specification defines: 90, 180, and 270 degrees. Pages at zero, or carrying a non-standard value, are left alone. And if the content was scanned at a slight angle to begin with, that is a skew in the image itself rather than a rotation flag, and is outside this tool's scope.
Files are handled up to 100 MB. Even long documents finish relatively quickly, since no rasterisation is involved.
When to run it
Run it once before you start working on a scan
PDFs that come out of a multifunction printer or a scanning app frequently carry rotation flags. If redaction, stamping, page extraction, or merging is coming next, normalising first saves you from chasing orientation and coordinate mismatches later on.
And since normalisation neither degrades the content nor meaningfully changes the size, running it "just in case" costs essentially nothing — which is what makes it easy to adopt as a standard first step.
Specs and limits
- Input format
- PDF (application/pdf)
- Size limit
- 100 MB per file
- Applies to
- Pages carrying a 90, 180, or 270 degree rotation flag
- Method
- Prepends a transformation matrix, then clears the flag
- Quality
- No rasterisation; text, vectors, and images untouched
- Text layer
- Remains selectable and searchable
- Size impact
- A few dozen bytes per normalised page
- Appearance
- Unchanged — this does not reorient the page
- Report
- Reports how many pages were normalised and skipped
- Network
- No file upload; all processing in-browser