Fix a photo’s orientation tag

One field, and the argument it starts

When you turn a phone on its side to take a picture, the sensor is turned with it and the samples are written in the order the sensor read them. Turning several megapixels before saving would cost time and a generation of quality for something the phone can describe in two bytes instead — so it writes the picture as read and adds a field, EXIF Orientation, saying how far round a viewer should turn it before showing it.

That works perfectly for as long as everything that opens the file reads the field. Your phone’s gallery does. Most desktop photo viewers do. A great many upload forms, document renderers, older email clients and print pipelines do not, and they show the samples exactly as stored — which is to say, on their side. Nothing is broken and no program is at fault; two of them simply disagree about the same file, and the file gives them the room to.

What each repair does to the bytes

• Baking the pixels decodes the picture, applies the transform the tag describes and writes the samples out again in their corrected order. For a JPEG saved with the camera block carried across, the original metadata comes with it and the field is set to 1 in the process; for a JPEG saved with that box unticked, and for any output the browser writes as PNG, there is no EXIF block in the result and so no field at all. The file then looks the same in every program ever written. The cost is a second generation of JPEG compression.
• Rewriting the tag opens the file, changes the orientation field to 1, unlinks the embedded preview and writes the rest through untouched. Nothing is decoded. It is instant and free, and it is the wrong repair if the samples really are stored turned, because it tells every viewer to stop correcting a file that needed correcting.

Both end with nothing in the file telling a viewer to turn it: the tag rewrite sets the field to 1, and baking either sets it to 1 alongside the metadata it carries across or leaves a file with no EXIF block for a viewer to consult. Either state is one two programs cannot disagree about. The difference is only which half of the file was made to match the other.

Questions about the orientation tag

Which of the two repairs do I want?

Ask where the file looked wrong. If it looks right on your own machine and wrong somewhere you sent it, the pixels are stored turned and the receiving program is ignoring the tag — bake the pixels. If it looks wrong everywhere including here, or if something has already turned it once and it now appears over-rotated in a viewer that reads tags, the pixels are already correct and the tag is the liar — rewrite the tag. The tool prints its reading of which case you are in, based on the value it found.

Is rewriting the tag really lossless?

Yes, in the strict sense: the compressed picture data is copied from the file you opened into the file that is written without being decoded, and the two files differ in the orientation field and in the four bytes that link to the embedded thumbnail. Nothing is requantised and no chroma is resampled, because nothing is decoded. It is the only operation on this site of which that is true.

Why does my file manager still show it sideways after I fixed it?

Almost always the embedded thumbnail. A camera writes a small preview into the EXIF block, and a great many file managers show you that preview rather than decoding the full picture. Correcting the main image while leaving a stale preview behind produces exactly the bug you were trying to fix. Both repairs here unlink that thumbnail so every reader regenerates it.

What happens to the GPS position?

The tag rewrite leaves it alone — that repair changes the orientation field and nothing else, so everything the file carried it still carries. Baking the pixels copies the original metadata block into the new file by default, GPS included; untick the box beside the quality slider and the saved file carries no metadata at all, which is the only honest way to say a location has been removed.

Can it tell me the orientation of a PNG?

There is nothing to tell. The Orientation field belongs to EXIF, which is a structure JPEG and TIFF carry and PNG, WebP and GIF do not in any way a browser acts on. For those formats, what you see is what the samples say, and a turn is the only repair available.

All eight values, including the four that include a mirror, are set out in the reference page. For a stack of scans that all carry the same defect, the batch page does the same repair to a queue and tells you what it did to each file.