A scanned form comes back with page 2 on its side. I press rotate in the viewer, it looks right, I close the file, and the next time it opens page 2 is sideways again. That's because most rotate buttons change how the viewer draws the page, not the file. Fixing it for good means changing one small number stored on each page. Below is what that number is, how to check it, and how to set it with free tools.

Everything here was run on a three-page dummy PDF with qpdf 12.4.2 and pdfinfo (poppler 25.03) on Linux.

Where rotation lives in a PDF

Each page object can carry a /Rotate entry: 0, 90, 180 or 270, meaning degrees clockwise. Viewers, printers and browsers read it and turn the page before drawing it. The page content itself isn't touched, so text stays selectable and scanned images keep their resolution. Changing it barely changes the file size.

The entry can also sit on a parent node of the page tree, in which case every page under it inherits it. That's why I check the value with a tool rather than searching the file for the text /Rotate.

View rotation versus saved rotation

Adobe's help page for Acrobat says it directly: Rotate View "changes the view of the page, not its actual orientation. You can't save this change." To keep it, Adobe points to Organize pages and Rotate page right or left, then saving the document (Adjusting PDF views, Adobe help).

The same split exists in other viewers, so I treat any rotate button as display-only until the saved file proves otherwise. On a Mac, Preview's Tools > Rotate Left and Rotate Right do change the pages once you save.

Check what the file actually says

pdfinfo -f 1 -l 3 scan.pdf | grep rot 

-f and -l are the first and last page to report. For my test file after one fix it printed:

Page 1 rot: 0 Page 2 rot: 90 Page 3 rot: 0 

The number already includes anything inherited from a parent node, so it's the value a viewer will use. For the page count, qpdf --show-npages scan.pdf.

Set it with qpdf

qpdf is free and open source, and it's in most package managers (apt install qpdf, brew install qpdf).

qpdf scan.pdf --rotate=+90:2 fixed.pdf 

The syntax is --rotate=[+|-]angle[:pages], and the sign matters:

  • +90 or -90 is relative: it turns the page from wherever it is now. Running --rotate=+90:2 twice took page 2 from 0 to 90 to 180.
  • 90 with no sign is absolute: it sets the page to 90 whatever it was. Running --rotate=90:2 on that 180 page brought it back to 90.

Page ranges follow qpdf's usual rules:

qpdf scan.pdf --rotate=+90 all.pdf # no range: every page qpdf scan.pdf --rotate=-90:1,3 some.pdf # pages 1 and 3 only qpdf scan.pdf --rotate=+90:2-z rest.pdf # page 2 to the last page 

On my test file, -90:1,3 left pages 1 and 3 at 270, which is the same as 90 counterclockwise. Relative rotation also takes inherited values into account: on a file whose parent node said 90, +90:1 gave page 1 a total of 180 and left the others at 90.

qpdf writes a new file and leaves the original alone, so keep the output name different from the input.

Things rotation can't fix

  • Only 90 degree steps. A scan that's a few degrees crooked needs deskewing, which means re-rendering the image.
  • Rotation doesn't crop or resize anything. A landscape page stays landscape-sized when turned.
  • A page that looks sideways because the scanner drew the content sideways still fixes the same way: the /Rotate value turns the whole page, whatever is inside it.

I built ToolOcean, and it has a rotate page that sets the same per-page value in the browser without uploading the file. Its page says form fields and bookmarks survive because the document is modified rather than rebuilt; I haven't tested that part myself. It's at toolocean.co/pdf-rotate.

Before you send the file, run pdfinfo on the copy you're actually attaching. The usual mistake is fixing one file and emailing the one next to it.

Drafted with AI help, tested and checked by me.