Why your photo is sideways on one site and not another

Your phone probably didn’t save the photo the way you held it. An iPhone 14 Plus picture we tested, shot in portrait, is stored as a 4032 by 3024 landscape image with one extra number in its EXIF data: Orientation 6, meaning “turn this 90° clockwise before you show it”. Every place that reads that number shows the photo upright. Every place that ignores it, or throws the EXIF block away without turning the pixels first, shows it on its side.

So the photo isn’t broken. Two programs disagree about one tag. We measured which ones read it, in Chromium 153 and in our own tools, on 24 September 2026.

The eight values, and what the test files look like

EXIF Orientation (tag 0x0112) has eight legal values. 1 is upright. 3 is upside down. 6 and 8 are the quarter turns; the iPhone photo above uses 6. 2, 4, 5 and 7 add a mirror image. Any other value, including 0, is invalid, and every path we tried treated 0 as 1.

Our test set is Dave Perrett’s exif-orientation-examples (MIT licence): the same landscape photo stored nine ways, Landscape_0.jpg to Landscape_8.jpg, each with its pixels pre-turned so that a viewer that honours the tag shows the same upright picture. We made PNG and WebP copies of values 1 to 8 with the same stored pixels and wrote the Orientation tag into them with ExifTool 13.55 (an eXIf chunk for PNG, an EXIF chunk for WebP). For each file and each way of drawing it, a script compared what appeared on screen with the upright reference and with the raw stored pixels.

What honours the tag in Chromium 153

Three things in that table weren’t what we expected.

WebP is ignored everywhere. A WebP file can carry the same Orientation tag as a JPEG, ExifTool reads it back without complaint, and Chromium draws the stored pixels anyway, through every path. If a WebP arrives sideways in Chrome, the tag won’t save it; the pixels have to be turned.

PNG is honoured. Chromium 153 turned our PNG copies, tag in an eXIf chunk, exactly as it turned the JPEGs.

And imageOrientation: 'none' didn’t switch anything off. MDN’s page for createImageBitmap() says none orients the image “ignoring any metadata about the orientation”. In Chromium 153 every JPEG and PNG still came back upright with it. If your code relies on that option to get the raw stored pixels, test it; stripping the EXIF segment before decoding is what worked for us. The CSS property image-orientation: none did show the stored pixels, for our same-origin files. MDN notes that it doesn’t apply to images from other origins.

Why the same photo turns sideways after an upload

The table shows that a modern viewer gets JPEG and PNG right on its own. The sideways photo usually comes from a step in between: a program that decodes the stored pixels without applying the tag, then saves them without EXIF. After that the tag is gone and nothing downstream can fix it. We haven’t tested which apps or sites do this; that includes Gmail, WhatsApp and every social network.

We did find the same fault in our own code while writing this. Our lossless metadata cleaner, the one behind the EXIF remover, already kept Orientation for JPEG. For PNG it removed the whole eXIf chunk, and seven of our eight PNG copies came out sideways or mirrored. Worse, its WebP path wrote the chunk header fields in the wrong order, so every cleaned WebP was a 12-byte file no decoder could open, oriented or not. Our synthetic test fixture had been built with the same mistake, which is why the tests passed. Both are fixed: a cleaned PNG now keeps a 26-byte eXIf with only the Orientation tag in it, and cleaned WebP files open again. WebP still loses the tag, which changes nothing in Chromium.

Turn the pixels or change the tag?

There are two ways to fix a sideways photo, and our Rotate or flip tool offers both. Changing only the tag keeps every byte of picture data: our turned copy of Landscape_1.jpg stayed at 339 KB and kept all its metadata. But it only helps where the tag is read, and it vanishes the first time some program strips EXIF.

Turning the pixels works everywhere and costs a re-save. We measured that cost against an exact turn of the decoded picture.

At quality 92, our default, all three stayed at 42 dB or better, and turning a photo four times cost between 0.2 and 1.1 dB more than turning it once. The file size is the surprise: at 92 the Nikon photo came out 59% bigger and Landscape_1.jpg 48% bigger, while the iPhone photo stayed the same size. If the size matters more to you than a few decibels, pick 85.

Our view: turn the pixels for anything you will upload or send, and change the tag only on files that stay in your own photo library, where you know the viewer reads it.

To see which value your own photo carries, drop it into the EXIF viewer: it lists the Orientation tag with the rest of the camera data, and says in words which way the picture is stored.