Rotate PDF pages
Turn the pages that came in sideways, without re-encoding anything.
How it works
Rotating a PDF page does not touch the page. Every page dictionary in the file can carry a /Rotate entry: a number of degrees, applied clockwise by the viewer at the moment it draws the page. Setting it changes one integer, and the content stream underneath, with its text operators and its embedded images, stays byte for byte what it was.
That is why this finishes about as fast as the file opens, why it is exactly lossless, and why the turn itself costs about eleven bytes per page rather than a re-render. What that does not promise is a file of the same size, because the document has to be written out again to save one changed integer. The FAQ below gives the measured range, and it is wider than you would expect. A tool that instead rasterises each page to a picture and turns the picture will produce something that looks similar and has thrown away every selectable word in the document.
Adding to the existing value
Because /Rotate is a value that already exists, the honest operation is to add to it rather than to assign over it. Scanners set it constantly: a page that displays upright may well be a sideways scan already carrying /Rotate 270, and the entry is inheritable, so a page can pick up a rotation from the page-tree node above it without holding one of its own.
This is the mechanism behind the familiar complaint that rotation will not stick. A tool that writes 90 onto every page you touch quietly un-rotates the pages that were already correct, and a page reading 270 turned one more quarter has to come out at 0, not at 90. Each page's current value is read here first and your quarter-turns are added to it, so a page that looked right before still looks right afterwards.
Why only quarter-turns
The available rotations are 90, 180 and 270 degrees clockwise. The format requires the value to be a multiple of 90 and viewers normalise anything outside that, so an angle like 45 degrees is not something a PDF page can express.
In practice quarter-turns are all this problem needs, because the cause is almost always a scanner. A document feeder takes pages however the person loading it happened to hold them; duplex scanning flips alternate sides, so the backs of sheets can land 180 degrees out; a landscape chart fed through a portrait feeder arrives on its side; and the automatic-orientation setting in most scanning software guesses from detected text, which means it straightens the dense pages, ignores the ones that are mostly a diagram, and now and then turns a page of tabular figures the wrong way.
A single pass over a single stack of paper can therefore produce three different orientations in one file, which is why per-page control is the point of this tool and rotating the whole document is the shortcut rather than the main event.
What rotating does not change
It is worth being precise about what has and has not changed. /Rotate is an instruction to whatever displays the page, not an edit to the page: the coordinate system of the content stream, the placement of form fields and annotations, and the orientation of any scanned image embedded in the page are all exactly as they were, and the MediaBox still describes the unrotated sheet.
Because only that one entry is written, the document is not rebuilt out of copied pages, and that separates this from reordering or merging. A fillable field is still fillable afterwards, carrying its current value, and bookmarks and document metadata come through intact.
Encryption and reader support
Encryption is worth separating into its two cases, because they are not the same thing: a tax form or statement locked only against printing or editing carries no password for you to type, and it is decrypted and rotated normally, while a document that genuinely needs a password to open is refused with an explanation, because this tool never asks you for a password.
Current viewers, browsers and printers honour the entry, so for reading, printing and emailing the page is upright. Software that goes straight at the page contents and ignores the attribute (some older OCR pipelines, image-extraction scripts, the occasional upload validator that measures page dimensions) will still see the original orientation. If you need the turn baked into the pixels rather than declared, the only route is to render the pages out as images, and that costs you the text layer.
Questions
Is my PDF uploaded?
No. The file is read into memory by this tab, the page dictionaries are edited by a PDF library running in a Web Worker, and the result is handed back as a download. Open the Network tab in developer tools before you drop the file: rotating a document produces no request carrying it and no request to any other origin. There is nothing to delete afterwards because nothing was ever received.
Why does rotation in other tools sometimes appear not to stick?
Because they overwrite the page's existing rotation instead of adding to it. Scans routinely arrive with a /Rotate value already set, so assigning 90 to a page that already reads 90 changes nothing you can see, and assigning it to the pages that were upright knocks those sideways instead. This tool reads the current value of each page and adds your change to it, which is also why turning a page four times brings it back to where it started.
Can I rotate one page only, or rotate by 45 degrees?
One page, yes: use the rotate button on that page in the grid, or type 4:90 into the per-page rotations field. 45 degrees, no: page rotation in PDF is stored as a multiple of 90 and there is nowhere to record an arbitrary angle. Rotating the artwork itself by an arbitrary angle is a different operation and a lossy one. Note that an entry of 0, such as 4:0, holds that page still even when “Rotate every page” is set.
Does rotating lose quality, and why did my file get bigger?
No quality is lost: no image is decoded and re-encoded, no text is re-laid out, and the rotation itself measured at about eleven bytes per page across a 127-page and a 138-page book. The size change is a separate thing, and it comes from having to write the whole document out again in order to save one changed integer. Measured on real files rather than test ones: two books came back 87% and 56% larger, a 28-page tax return 7% larger, documents without compressed cross-reference structures within about 2% either way, and one government form 36% smaller. The pattern is structural. Files carrying /ObjStm and /XRef streams pay the most, because that compact cross-reference layout is what gets written back out plainly. It is redundancy rather than lost detail: gzipped, those larger outputs sit within 4% to 6% of the originals, so it compresses away in transit and every page still draws identically. The compress tool here cannot undo it either. That one re-encodes images, and the two most inflated files are text and vector graphics with nothing for it to work on, so it hands them straight back unchanged. On a text-heavy document where the byte count matters more than the orientation, keeping the original is the better trade.