English ▾
Free, Fast & Secure Online Tools
You take a photo in portrait. It looks correct on the phone, correct in the gallery, correct when you email it to yourself. Then you upload it somewhere and it is lying on its side. Nothing rotated the image. The pixels never moved. What changed is who was reading them.
A camera sensor is a fixed rectangle, physically bolted into the body in one orientation. When you turn a phone sideways to take a landscape photo, the sensor does not turn with you — it captures the same rectangle it always captures.
So how does the photo come out the right way up? The phone detects which way it was being held and writes that down. Not by rearranging the pixels, which would cost time and battery, but by storing a small note in the file’s metadata: the EXIF orientation tag.
The tag holds one of eight values. In plain terms it says something like “rotate 90° clockwise before displaying” or “this is already upright”. The pixel data is identical either way; only the instruction differs.
Every program that opens the image has to choose whether to obey that instruction. Most modern software does. Some software does not — and plenty of upload pipelines strip metadata for privacy or file-size reasons, which removes the instruction entirely.
The result is a photo that is simultaneously correct and sideways, depending on who is looking:
This is why the problem feels random. It is not random — it is a disagreement between programs about a note that was always there.
Metadata removal is usually a good thing. EXIF carries GPS coordinates, the device model, the exact timestamp — information most people do not intend to publish along with a photo. Many services strip it by default, and they are right to.
But the orientation tag lives in the same block as the GPS coordinates. Remove the block and you remove the rotation instruction with it. The photo now displays using its raw pixel orientation, which is whatever the sensor happened to capture — sideways, if you held the phone sideways.
The reliable solution is to rotate the image data itself, so the pixels are upright and the orientation tag becomes unnecessary. This is sometimes called “baking in” the rotation. After that, every program agrees, because there is nothing left to disagree about.
The steps are simple:
One caution. Some editors “rotate” by changing the EXIF tag rather than moving pixels — fast, lossless, and completely useless for this problem, because it recreates the exact situation you are trying to escape. The test is to upload the result somewhere that strips metadata and see whether it stays upright.
A single sideways photo is an annoyance. A hundred of them, half landscape and half portrait, all mixed together, is a real problem — because you cannot apply one rotation to the whole set. Each photo needs the rotation its own tag specifies.
Anything that rotates based on each file’s existing orientation tag handles a mixed batch correctly. Applying a blanket “rotate everything 90°” fixes half the set and breaks the other half.
Dimensions appear swapped. A portrait photo reports 4032 × 3024 instead of 3024 × 4032. That is the honest pixel dimension; the tag was going to fix it at display time.
The thumbnail is upright but the full image is not. EXIF can embed a small preview image, and that preview may already be rotated. The viewer shows the correct thumbnail and the sideways original.
It is correct in one browser and not another. Browsers have handled orientation differently over the years, particularly for images inside CSS backgrounds versus <img> tags.
If you are preparing photos for a website, print service or anything where you will not see the result immediately, baking in the rotation before you hand the file over is worth the extra step every time.