Why your photo appears sideways after uploading

It looks right on your phone. It looks right in the preview. Then it lands sideways on the website. The pixels never moved — only a note attached to them.

Updated 28 August 2026 · 11 min read

The photo looks right on your phone. It looks right in the little preview the upload form shows you before you press submit. Then the page reloads and there it is, lying on its side, a portrait of somebody who appears to be asleep on a wall.

Nothing has been damaged and nothing has been lost. The file is exactly the same as it was. What changed is who is looking at it, and whether that particular piece of software agrees to read a single small number stored alongside the pixels.

The sensor does not turn when you do

A camera sensor is a rectangle bolted into the body of the phone. When you turn the phone on its side to take a portrait shot, the sensor turns with it — relative to the world it is now sideways, but relative to itself nothing has happened. It still reads out its rows in the same order, starting from the same physical edge, exactly as it does for every other photo.

So the pixel data that lands in the file is in the sensor's frame of reference, not yours. In a portrait photo taken on a typical phone, the picture stored on disk is a wide landscape image with your subject lying flat across it.

The camera knows this, because it has an accelerometer and it knows perfectly well which way up the phone was. It has two options for dealing with it.

The first is to rotate the pixel data before saving: decode what the sensor produced, turn it a quarter turn, and write the result. That costs time on a device that is trying to be ready for the next shot within a fraction of a second, and for JPEG it can cost a little quality, because the straightforward way to do it involves decoding and re-encoding the image.

The second option is to write down what needs to happen and let somebody else do it. This is the one every phone takes. Along with the pixels, the file carries a block of EXIF metadata — camera model, exposure, date, often GPS coordinates — and inside that block sits a field called the orientation tag, formally tag 0x0112. It holds a small integer. In effect it says: display this rotated 90 degrees clockwise.

The tag is a note taped to the back of a framed picture saying which edge goes up. It is not part of the picture. It only works if whoever hangs it bothers to look.

The eight values the tag can hold

There are eight defined values: four rotations, and the same four again with a horizontal mirror applied first. The mirrored ones exist because some cameras — front-facing ones in particular — read out their sensors flipped.

In practice you will meet 1, 6 and 8 constantly, 3 occasionally, and the mirrored four almost never. Note also that programs describe these values in different words: 8 may be shown as “rotated 270 clockwise” in one place and “rotated 90 anticlockwise” in another, and 4 may appear as “mirrored vertically” or as “mirrored and rotated 180”. Those pairs are the same transformation written two ways, not a disagreement about the file.

Why two programs show you two different pictures

Software that reads the orientation tag applies the transformation and shows you the photo the right way up. Software that ignores the tag draws the raw pixels and shows you the photo on its side. Both are being perfectly honest. Both are showing you the same file.

That is the whole mystery. There is no corruption, no failed upload, no half-written file. There is one image and two reasonable-but-incompatible readings of it.

The reason it bites specifically at upload time is that a photo passes through a long chain of programs, and the chain has many links written by different people at different times. The camera app writes the file. The phone's gallery displays it. The operating system's file browser makes a thumbnail. The browser renders a preview of the file you selected. Something on the receiving end decodes it, probably resizes it, and stores a version. A page then displays that version. Any one of those steps may honour the tag, ignore it, or discard it — and behaviour varies between programs, between versions of the same program, and between the different code paths inside one program. It is entirely normal for a viewer to get it right while the resizer sitting behind the same website gets it wrong.

Which is why “but it looks fine on my computer” is true, unhelpful, and not evidence of anything. You cannot determine the state of a file by looking at one program's rendering of it.

How to see the tag instead of guessing

Guessing which way a photo “really” is leads to rotating things by hand until something looks right somewhere, which is how people end up with photos that are wrong in a new and more interesting direction. Read the number instead.

Two things are worth checking together. First, whether an orientation entry appears at all. Second, the stored pixel dimensions. If a photo you took in portrait reports dimensions that are wider than they are tall, the file genuinely does contain a landscape image, and it is relying on the tag to be turned upright. That combination — wide stored dimensions plus an orientation of 6 or 8 — is the signature of the problem.

If no orientation entry shows up, that is informative too. It may mean the file has already been through something that normalised it, or that it never had one. EXIF lives in JPEG files far more reliably than in other formats; PNG files, and therefore most screenshots, rarely carry it at all.

The permanent fix is to make the tag redundant

Any fix that leaves the instruction and the pixels disagreeing is temporary, because the next program in the chain gets a fresh vote. The durable fix is to remove the disagreement entirely:

1. Decode the image.
2. Apply the transformation the tag asks for, so the pixels themselves are now the right way up.
3. Write the pixels out in that new arrangement.
4. Set the tag to 1, or do not write a tag at all.

After that, every viewer in the world agrees, because there is nothing left to interpret. A program that reads the tag finds either nothing or an instruction to do nothing. A program that ignores tags draws the pixels, which are already correct.

The cost is one re-encode. For a JPEG saved at a high quality setting that is visually invisible, and it is the same cost you already pay for any edit. It is worth doing once, early, rather than fighting the same photo through four different systems.

The photo that arrives rotated twice

There is a second, nastier failure mode, and it is worth recognising because it looks like the tool you used made things worse.

Some software rotates the pixels correctly but then forgets to clear the tag. You now have an upright image still carrying an instruction that says rotate this 90 degrees clockwise. Any program that ignores the tag shows it correctly. Any program that honours the tag dutifully rotates it a second time and shows it on its side — in the opposite direction to the original fault.

The tell is that the picture is wrong in the program that was previously right, and right in the program that was previously wrong. If a rotation appears to have inverted which of your programs is correct, this is what happened. The remedy is the same as before: run the file through something that applies the tag and then clears it, so the double instruction cannot survive.

Stripping metadata at exactly the wrong moment

This is the one that catches careful people, because it is a side effect of doing something sensible.

People hit this while cleaning photos for privacy, which is a good reason to strip metadata: EXIF routinely carries the coordinates of the place a picture was taken, which is a real problem when the place is your home. That is worth doing, and there is more on it in removing GPS data from photos. But the order matters. Apply the rotation, then strip.

A tool that decodes with orientation honoured and re-encodes from the resulting pixels gets this right by construction, because the rotation is already in the pixels before the metadata is dropped. That is how the tools on this site work — the decoder is asked to apply the tag, and the output file is written from that canvas with no metadata block at all. It is worth checking that whatever you use behaves the same way, because the failure is silent and the original data is not recoverable from the result.

Why it is portrait photos, and why it is phones

Hold a phone in the ordinary landscape position and the recorded pixels already match the world. The camera writes an orientation of 1, no transformation is requested, and every program in the chain reaches the same conclusion whether it read the tag or not. A pipeline can be entirely broken and you would never know.

Turn the phone upright and the same pipeline has to make a decision, and now half of it makes a different one. Portrait photos are not more fragile; they are simply the case that tests the code. The consequence is also worse: a 90-degree error swaps the aspect ratio as well as the direction, so a tall photo becomes a wide one. Layouts break, automatic crops take a slice of the wall instead of a face, and a resize to “1200 pixels wide” produces something with entirely the wrong dimensions — which is a good reason to settle orientation before you start resizing. The same applies when photos are being assembled into a document: page orientation is chosen from the image dimensions, so a sideways photo produces a sideways page when you combine photos into a PDF.

As for why phones rather than anything else: a phone camera is close to the only device that routinely writes a value other than 1. A flatbed scanner produces its image in a fixed orientation and has no reason to claim otherwise. A screenshot is generated from the screen in the orientation of the screen, and is usually a PNG carrying no EXIF at all. Images downloaded from large platforms have often already been normalised on the way through. That leaves handheld cameras, which is where an accelerometer and a fixed sensor come into conflict several times a day.

Common questions

Why does it look correct on my phone and wrong on the website? Because the phone's gallery reads the orientation tag and whatever processed the file on the website did not, or dropped it along the way. Both are displaying the same file; they disagree about one number in it.

Will rotating the photo in a viewer fix it? Sometimes, and it depends entirely on what the viewer writes back. If it rotates the pixels and clears the tag, yes, permanently. If it only changes the tag, the file is unchanged for anything that ignores tags. If it rotates the pixels and leaves the tag alone, you get the rotated-twice problem. This is the sort of thing worth verifying by reading the tag afterwards rather than trusting the preview.

Can I fix it after I have already stripped the metadata? Only by rotating it manually, and you have to know which way. The instruction is gone, so nothing can infer the intended direction from the file — the information that would have told you is what you deleted. Rotating by hand does work; it is simply guesswork rather than a repair.

Does the tag affect the file size or the quality? The tag itself is a couple of bytes and changes neither. Baking the rotation into the pixels requires re-encoding, which for a lossy format costs a small amount of quality — negligible at a high quality setting, and paid once.

My HEIC photos do this too. Is it the same thing? The same principle applies: the orientation is recorded as metadata rather than by turning the pixels. Support for reading it varies more widely than it does for JPEG, so converting to JPG with the rotation applied is often the shortest route to a file that behaves everywhere.

Why does one photo from the same set come out fine? Almost certainly because it was taken in landscape, so its tag is 1 and no transformation is requested. Photos with an orientation of 1 travel through broken and correct pipelines identically.