Why a PDF page "rotates by itself" on some devices, and what rotating actually changes

A scanned contract arrives sideways. You rotate it in your viewer, it looks fine, you email it, and the recipient opens it sideways again. Or a landscape spreadsheet prints portrait, cut off, on a printer that showed it correctly in the preview. Or a PDF looks upright on a laptop and wrong on a phone. These are all the same phenomenon, and it comes from a design decision in the PDF format that is sensible on its own and confusing in combination with software that handles it inconsistently.

Two ways a page can be sideways

Every PDF page has a media box: a rectangle in points defining the page's size, for example 595 × 842 for A4 portrait. Content — text, images, lines — is drawn inside that box in a coordinate system whose origin is at the bottom-left. If a scanner captures a landscape sheet, it can do one of two things. It can produce a page whose media box is 842 × 595 (landscape) with the content drawn upright inside it. Or it can produce a page whose media box is 595 × 842 (portrait) with the content drawn rotated 90 degrees inside it — the way it physically passed through the scanner — and then add an instruction saying "display this page rotated".

That instruction is the /Rotate entry in the page dictionary. It takes one of four values — 0, 90, 180 or 270 — and tells the viewer to rotate the page clockwise by that amount when displaying or printing it. It is a single number attached to the page; the content stream is untouched. Almost every scanner, and every tool that offers a "rotate" button, uses this mechanism, because it is instantaneous and lossless: nothing is re-drawn, nothing is re-encoded.

Why viewers disagree

The specification is clear that /Rotate must be honoured, and every proper PDF viewer does. The problems arise around the edges. Thumbnail generators and some image-conversion pipelines render the media box and ignore /Rotate, producing sideways previews of a document that opens correctly. Some printer drivers apply /Rotate and then apply their own auto-rotation for landscape content, ending up 90 degrees off. Some mobile apps let you rotate a page "for viewing" without writing anything to the file, so the fix vanishes the moment the file is shared — this is the "I rotated it and it came back" case, and it is not the recipient's fault.

There is also a second-order confusion. A page with /Rotate 90 has a portrait media box and displays landscape. A tool that asks "what size is this page?" gets 595 × 842 and reports portrait; a tool that asks "how is this page displayed?" says landscape. Both are correct, and code that mixes them up produces the classic symptom: page numbers stamped in the wrong corner, watermarks running the wrong way, or a merged document where some pages are the "wrong" orientation because the merger normalised /Rotate on some inputs and not others.

What "rotate" tools actually do

Our rotate and organize tools set /Rotate. When you rotate a page 90 degrees, pdfcpu (the Go engine running in your browser) adds 90 to the page's existing /Rotate value, modulo 360, and writes the file back. The content stream is byte-for-byte identical; the file barely changes size; the operation takes milliseconds regardless of what is on the page. This is the right default for nearly all purposes: it is reversible, lossless, and every conforming viewer displays and prints the result correctly.

The alternative — actually transforming the content so that the media box becomes landscape and the drawing commands are rotated inside it — is what you get when you export the pages to images and rebuild the PDF, or when a tool offers to "flatten" rotation. The result has /Rotate 0 and a media box that matches how the page looks. It is the version to produce when the file will go through software that ignores /Rotate (some archival systems, some print workflows, image-based pipelines) or when it will be edited by tools that get the two coordinate systems confused. The cost is that rasterising loses text, and that a true content transform is a heavier operation than setting a number.

Fixing a document for good

1. Rotate in a tool that writes to the file, not in a viewer's "view" menu. In Acrobat Reader, "Rotate View" changes nothing; "Rotate Pages" (Pro, or a tool like ours) does. Check by closing and reopening the file.
2. Rotate the specific pages, not the whole document, when a scan mixes orientations. Our organize tool shows thumbnails of every page and lets you rotate them individually before saving.
3. After rotating, apply any stamps — page numbers, watermarks, signatures — so they are placed relative to the displayed orientation. Stamping first and rotating afterwards is how numbers end up sideways.
4. If the file is going into a system known to ignore /Rotate, or if a recipient reports it sideways after you fixed it, produce a flattened copy: export to images and rebuild, accepting the loss of selectable text, or use a tool that transforms content. Send that one.
5. For scans you control, fix the orientation at capture. Our scan tool builds each page from the straightened photo exactly as you framed it, so a sheet photographed upright produces a page with /Rotate 0 and upright content from the start; one photographed sideways needs a pass through the organize tool afterwards.

The mobile case

Phone photos add one more layer: the image itself may carry an EXIF orientation tag, which is the image-format equivalent of /Rotate. A photo taken in landscape is often stored as portrait pixels with a tag saying "rotate 90 to display". When such an image is placed into a PDF by a tool that ignores EXIF, it appears sideways inside an upright page — and no amount of page rotation fixes it, because now the page is upright and the picture inside it is not. The remedy is to apply the EXIF rotation to the pixels before building the PDF; modern browsers do this automatically when they decode a photo, which is what our image-to-PDF tool relies on. If you see this symptom, re-create the PDF from the images rather than rotating pages.

The short version

A sideways page is rarely a broken file. It is either a page whose /Rotate entry was never set (the scanner did not bother), a page whose /Rotate is being ignored by one particular piece of software, or a rotation that was only ever applied to the view and never saved. Setting /Rotate fixes the first and third for every proper viewer; flattening fixes the second at the cost of some fidelity. Knowing which situation you are in is most of the fix.