Why is My Photo Sideways? Understanding the EXIF Orientation Tag

Separate stored pixels from display instructions

A photo can store a sideways pixel grid and still appear upright because software applies its EXIF Orientation instruction. Other files already have upright pixels. Do not assume every portrait needs rotation, or that Orientation explains every sideways image: an incorrect export or a rotation saved into the pixels can also be responsible.

The goal is to establish two things: what the pixel data contains, and which transformation the viewing software applies. Deleting a tag is not the same as rotating pixels.

What the eight values mean

The following describes the transformation from stored pixels to intended display. CW means clockwise. For diagonal reflections, top-left and bottom-right refer to the corners of the stored image.

Value	Display transformation
1	No transformation
2	Reflect left to right
3	Turn 180 degrees
4	Reflect top to bottom
5	Transpose across the top-left to bottom-right diagonal
6	Turn 90 degrees CW
7	Reflect across the top-right to bottom-left diagonal
8	Turn 270 degrees CW, equivalent to 90 degrees counterclockwise

Values 5 through 8 swap the displayed width and height. Values 2, 4, 5 and 7 include reflection, so checking only whether a photo is upright misses mirrored text. Compare the ExifTool Orientation definitions and exifr orientation/rotation APIs. A reader may show a translated label rather than the raw number.

Diagnose before changing anything

1. Preserve the original. Open a working copy in the EXIF Viewer and look for Orientation in the all-fields tab.
2. Compare it in the application where the problem occurs. Use readable writing or an asymmetric object to detect reflection.
3. Note both stored dimensions, if available, and displayed dimensions. Swapped dimensions are a clue, not proof of damage.
4. Ask what changed: was metadata removed, were pixels rotated, or did a second application apply orientation again?
5. If the tag is absent or the viewer returns no fields, do not guess a value. Inspect with another reader; the viewer does not display every possible structure or error.

Consider a synthetic image whose stored grid is 120 by 80 with Orientation 6. Its intended display is 80 by 120. Removing only the tag can expose the sideways 120-by-80 grid. Rotating the pixels upright but retaining a stale value 6 can instead cause a second rotation. The same principle applies to reflected cases.

Two different repair strategies

Correct the instruction: a metadata-aware external editor can adjust a wrong Orientation value without intentionally re-encoding image pixels. This only helps if the correct interpretation of those pixels is known and the destination honors the tag. ExifCheck’s JPEG EXIF Editor does not expose Orientation; do not use its date, description or GPS fields as an orientation workaround.

Normalize the displayed image: apply the intended transformation to the image data, then remove the old instruction or set it consistently to normal. A general image-editor export may re-encode JPEG. Specialized lossless JPEG transforms have their own constraints; “rotate” does not automatically mean lossless.

What the browser remover actually does

The EXIF Remover loads an image through the browser decoder, draws that decoded image onto canvas using its natural dimensions, and encodes a new file. It relies on the decoder’s handling of orientation; there is no separate Auto-Orient switch or manual eight-value transform in this tool.

Preservation of displayed orientation has been checked in synthetic cases, including an Orientation-6 JPEG smoke test documented in the project. That does not establish correct behavior for every browser, operating system, image format or real camera file. The synthetic metadata lab provides controlled examples, not a universal compatibility certificate.

Re-encoding also changes the tradeoff: JPEG and WebP can change through lossy compression, even at maximum quality. PNG encoding is lossless, but browser decoding and color conversion do not guarantee source-pixel identity. The HTML canvas serialization specification describes new bitmap output, not an in-place metadata edit.

Verify the downloaded result

Reopen the downloaded copy, rather than trusting only the preview. Check its orientation tag, upright appearance, mirrored letters, dimensions and color. Test in the actual destination application, especially if that was where the original failed. A normal or absent tag is not enough if the pixels themselves are still wrong.

For sharing, also review GPS and identifying text: a correctly oriented photo is not automatically private. See EXIF field interpretation and PNG versus JPEG metadata before choosing a removal workflow.