I have a lot of photos taken with an iPhone SE that are not displayed in the correct orientation when I view them using the Windows Photos app, XnView MP, or FastStone Image Viewer. I never modified these photos when they were on the iPhone or after I transferred them to my PC.

There are numerous answers on StackExchange (just a few examples: here, here, here) saying that you can use Jhead with the -autorot option to automatically correct the orientation of your photos based on the EXIF orientation field.

So I tried using Jhead 3.04 with jpegtran on Windows. Before running Jhead, I made backup copies of the photos and also ran ExifTool on a couple of the photos and saved the output. Then I ran jhead -autorot *.jpg on the photos.

When I viewed the modified photos in the Windows Photos app, XnView MP, and FastStone Image Viewer, they were all still displayed in the same incorrect orientation as before.

Then I ran ExifTool on one of the modified photos as well as the backup copy, and compared the outputs. These are the EXIF fields that Jhead changed:

  • Orientation changed from "Rotate 90 CW" to "Horizontal (normal)"
  • Thumbnail Length changed from 12925 to 11906
  • Image Width changed from 4032 to 3024
  • Image Height changed from 3024 to 4032
  • Image Size changed from 4032x3024 to 3024x4032
  • Thumbnail Image changed from "(Binary data 12925 bytes, use -b option to extract)" to "(Binary data 11906 bytes, use -b option to extract)"

I also diffed the modified photo with the backup copy, and Jhead also changed the photo data itself in addition to the EXIF data.

Then I tried Jhead with the -norot option to see what would happen. After running jhead -norot *.jpg on another set of backup copies of the photos, the photos were all displayed in the correct orientation in Windows Photos, XnView MP, and FastStone Image Viewer.

Again I ran ExifTool on the same photo as before, comparing the outputs for the modified one and the backup copy. Only one EXIF field was changed by Jhead using the -norot option:

  • Orientation changed from "Rotate 90 CW" to "Horizontal (normal)"

And diffing the modified photo with the backup copy showed that only that EXIF field changed, none of the photo data was changed.

So why is it that using Jhead with the -autorot option is a highly recommended way to automatically correct photo orientation, but it doesn't work for me, and I have to use the -norot option instead?


2 Answers 2


This is a case of everything working as intended, but having incorrect input (i.e., garbage in, garbage out).

Two images, the original and after running jhead -autorot, should both display the same on Windows Photo app, as well as most modern image viewers. Your Windows was working as intended. It was the images from your iPhone SE that had incorrect EXIF image orientation tag information.

jhead -autorot rotates the image data, as well as thumbnail data, to match what the image would look like with the EXIF orientation tag interpreted correctly, and then sets the EXIF orientation tag to 1 (Normal).

jhead -norot simply sets the EXIF orientation tag to 1 (Normal), without modifying the image data.


AFAIK (all my digital cameras and smartphones so far, but I don't know if the iPhones do it like everyone else) pictures out of the camera are encoded as the sensor got them (which means "portrait"), and an "orientation" flag is added to rotate them adequately (and sometimes to mirror them).

For instance, two pictures from my phone, as reported by exiftool(*):

enter image description here

>>>exiftool -ImageWidth -ExifImageWidth -ImageHeight -ExifImageHeight -Orientation Orientation-*
======== Orientation-Landscape.jpg
Image Width                     : 4000
Exif Image Width                : 4000
Image Height                    : 2250
Exif Image Height               : 2250
Orientation                     : Horizontal (normal)
======== Orientation-Portrait.jpg
Image Width                     : 4000
Exif Image Width                : 4000
Image Height                    : 2250
Exif Image Height               : 2250
Orientation                     : Rotate 90 CW
    2 image files read

Starting with such images, either you:

  1. change the orientation flag, and don't change anything else
  2. actually rotate the pixels (and remove the orientation flag).
  • When you do the first one, the picture dimensions do not change, and all your photos should be still be reported as being having width greater than the height, which is normally how they come out of the camera. You can use exiftool to change the orientation flag, see this answer.
  • When you do the second, the picture dimensions(*) will reflect the orientation and the portrait image will have a height greater than the width (but the orientation flag should not longer be there, or have been set to the default).

There are also picture editors that do the wrong thing:

  • when loading the image, they take the orientation flag in account and load the image with the expected portrait orientation
  • after editing, the image is saved encoded in portrait orientation
  • the EXIF data (including the orientation flag) is faithfully copied to the edited picture, and so doesn't match the new orientation. Then you image viewer faithfully takes the invalid orientation flag and shows the image on its side.

If this isn't enough to solve your problem, please run the exiftool command above on your pictures, and add the result to your question.

(*) and other utilities (the three I used do this: exiftool, ImageMagick identify, and the Unix file utility), some other could try to be clever and swap with and height to take in account the orientation flag.

  • \$\begingroup\$ Did you mean to say that photos are encoded by the camera in landscape mode before adding the Orientation flag? At least that's how photos from a DSLR and my iPhone appear when I remove all of their EXIF data. \$\endgroup\$ Commented Dec 31, 2022 at 22:31
  • \$\begingroup\$ Exactly, but not just "landscape"... if you shoot with the camera upside down, the photo without the orientation flag will also be upside down. So it's really encoded starting with the same sensor corner. \$\endgroup\$
    – xenoid
    Commented Dec 31, 2022 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.