You take a portrait photo. It looks fine on your phone. You email it, and the recipient sees it lying on its side. Nobody rotated anything. The explanation is a single number stored alongside the image — and once you understand it, a whole family of confusing photo problems becomes obvious.
What is actually happening
Your camera sensor is fixed in the phone's body, so it always captures a landscape image regardless of how you hold it. Rather than rotating millions of pixels, the camera writes a small metadata tag — EXIF Orientation — saying "turn this 90° when displaying". Software that reads the tag shows it upright. Software that ignores it shows the raw sideways data.
Why cameras do this
A phone's image sensor is soldered to the board in one fixed orientation. When you turn the phone, the sensor turns with it — but it still reads out pixels in the same order relative to itself. Rotate the phone 90° and the scene lands sideways on the sensor.
The camera could rotate the pixel data before saving. It does not, for two good reasons:
- Speed. Rotating a 48-megapixel image takes real time and battery. In burst mode, shooting several frames a second, that cost is prohibitive.
- Quality. A JPEG is compressed in 8×8 pixel blocks. Rotating means decoding, rotating and re-encoding — losing a little quality on every save.
Writing a single byte of metadata is instant and lossless. The design is sound. The problem is that honouring it is optional, and for twenty years a great deal of software simply did not bother.
The eight orientation values
| Value | Meaning | To display correctly | How common |
|---|---|---|---|
| 1 | Normal | Nothing | Very common — landscape shots |
| 2 | Mirrored horizontally | Flip horizontally | Rare |
| 3 | Upside down | Rotate 180° | Common — phone held inverted |
| 4 | Mirrored vertically | Flip vertically | Rare |
| 5 | Mirrored and rotated 90° CCW | Flip, then rotate | Very rare |
| 6 | Rotated 90° CCW by the camera | Rotate 90° clockwise | Very common — portrait shots |
| 7 | Mirrored and rotated 90° CW | Flip, then rotate | Very rare |
| 8 | Rotated 90° CW by the camera | Rotate 270° clockwise | Common — portrait, other way up |
In practice only 1, 3, 6 and 8 occur with any frequency. The mirrored values exist because the specification was designed for scanners and film digitisers as well as cameras, where a negative could genuinely be fed in backwards. They occasionally appear from front-facing cameras that mirror the preview.
💡 Why the numbers are not in a sensible order
The values are not arbitrary — each encodes a transformation of the two image axes. Values 1 to 4 preserve which axis is which, while 5 to 8 swap rows and columns. Within each group the variants cover the mirroring options. It is a compact encoding of the eight ways to map a rectangle onto itself, which is mathematically tidy and completely unintuitive to read.
Which software honours the tag
| Software | Honours orientation? |
|---|---|
| Phone photo galleries | Always |
Modern browsers (<img>) | Yes — default since around 2020 |
| Windows Photos, macOS Preview | Yes |
| Photoshop, Lightroom, GIMP | Yes, usually with a prompt |
HTML <canvas> drawing | No — raw pixels only |
| Most server-side image libraries | Usually not unless told to |
| Older desktop viewers | Often not |
| Email clients | Inconsistent |
| Some CMS thumbnail generators | Frequently not |
This table explains the most common version of the problem: a user uploads a photo that looks perfectly upright in their gallery, the server generates a thumbnail with a library that ignores EXIF, and the thumbnail comes out sideways while the full-size image — displayed by the browser, which does honour it — looks correct. Same file, two different renderings, on the same page.
⚠️ Canvas strips orientation silently
Any browser-based image processing that draws to a <canvas> gets the raw pixel data, with the orientation tag not applied. So an image that displays correctly in an <img> tag comes out sideways the moment you resize or crop it via canvas — and because the output is new pixel data with no EXIF, it stays sideways forever.
The fix is to read the orientation first and apply the matching transform to the canvas context before drawing, or to use createImageBitmap with { imageOrientation: 'from-image' }, which handles it for you.
The double-rotation problem
Here is the sequence that produces a photo which is wrong in a new way after you tried to fix it:
- Photo has sideways pixels and
Orientation = 6. Tag-aware software shows it upright. - You open it in an editor that ignores EXIF. It shows sideways.
- You rotate it 90° and save. The pixels are now upright.
- The editor leaves
Orientation = 6in the file, because it never read it. - Tag-aware software now rotates the already-upright pixels another 90°.
The photo is now correct in the software that was wrong before and wrong in the software that was right. Rotating again just swaps which half of your applications are broken.
✅ The only stable fix
Rotate the pixels to upright and set Orientation to 1. Once the raw data is correct and the tag says "no rotation needed", every piece of software agrees — those that read the tag and those that ignore it. This is what a proper "auto-orient" function does, and it is why doing it by hand so often fails.
Fixing it properly
Lossless rotation — the right way for JPEG
JPEG compresses in 8×8 blocks. Those blocks can be rearranged and rotated without decoding them, which means a rotation with no quality loss at all. jpegtran does exactly this:
One caveat on lossless rotation: it only works cleanly when the image dimensions are multiples of 8 (or 16 with chroma subsampling). Where they are not, the edge blocks cannot be rearranged, and tools either trim a few pixels or fall back to re-encoding. For camera photos, which have conveniently round dimensions, this rarely comes up.
Reading and setting the tag
Handling it in code
🚨 Always auto-orient before resizing on a server
If you resize first and orient afterwards, you have already produced a sideways thumbnail — and resizing usually discards the EXIF, so there is nothing left to correct with. .rotate() before .resize(), every time. This one line ordering is behind a large share of sideways-avatar bugs.
The privacy interaction
EXIF carries more than orientation. It commonly includes GPS coordinates, the exact date and time, the camera's serial number, and sometimes the owner's name. Stripping it before publishing a photo is sound practice.
But stripping metadata removes the Orientation tag along with everything else. If the pixels were sideways and relying on the tag, the photo is now permanently sideways in every application, with no way to recover the original intent.
Strip metadata without breaking your photos
Remove GPS coordinates, timestamps and camera details before you share — in your browser, so the photo is never uploaded anywhere.
Open the EXIF Remover →Which formats carry orientation
| Format | Supports EXIF orientation? | Notes |
|---|---|---|
| JPEG | Yes | Where the problem overwhelmingly occurs |
| HEIC / HEIF | Yes | Apple's default photo format |
| TIFF | Yes | EXIF originated as a TIFF extension |
| WebP | Yes, optionally | Support varies by encoder |
| AVIF | Yes | Uses its own transformation properties |
| PNG | No | No orientation concept — pixels are always as stored |
| GIF | No | Same |
| BMP | No | Same |
This gives a useful diagnostic shortcut: converting a JPEG to PNG bakes in whatever the converter decided. If the converter honoured the tag, the PNG is upright forever. If it did not, the PNG is sideways forever. Either way the ambiguity is gone — which is occasionally the quickest way to settle a stubborn case.
Diagnosing a specific file
- Read the tag.
exiftool -Orientation# photo.jpg. If it returns 1 or nothing, EXIF is not your problem. - Compare two viewers. Open the file in a browser and in something that ignores EXIF. Different results confirm the diagnosis immediately.
- Check where in your pipeline it breaks. Upload, thumbnail generation, and display are three separate stages and any one can be the culprit.
- Fix at the source. Auto-orient on upload, once, before anything else touches the file. Every downstream stage then works with unambiguous data.
Summary
- Cameras store photos in sensor orientation plus a tag saying how to turn them — it is faster and lossless.
- Only values 1, 3, 6 and 8 appear in practice.
- Honouring the tag is optional, which is why the same file looks different in different software.
- Canvas ignores it, so browser-based editing silently produces sideways output.
- Fix both the pixels and the tag. Changing one without the other creates the double-rotation problem.
- Auto-orient before stripping metadata, or you lose the orientation permanently.
- Auto-orient before resizing on a server, never after.
- Use lossless rotation for JPEG so quality is not lost on every fix.
Frequently Asked Questions
Why does my photo look correct on my phone but sideways on my computer?
The image data itself is sideways. Your camera stored the picture in the sensor's native orientation and added an EXIF Orientation tag saying how to turn it. Software that reads that tag displays it correctly; software that ignores it shows the raw sideways data. Nothing is wrong with the file — the two programs simply disagree about whether to honour the tag.
What are the 8 EXIF orientation values?
1 is normal, 3 is 180 degrees, 6 is rotate 90 clockwise to display, and 8 is rotate 270 clockwise. Values 2, 4, 5 and 7 add mirroring and are rare outside front-facing cameras. In practice you will only ever see 1, 3, 6 and 8.
Why does rotating my photo not stick?
Some editors rotate by changing the EXIF flag rather than the pixels. That looks fixed in software that honours the tag and unchanged in software that ignores it. Others rotate the pixels but leave the old tag in place, so tag-aware viewers apply the rotation a second time and the photo ends up wrong in the opposite direction.
Does removing EXIF data fix or break orientation?
It usually breaks it. Stripping metadata for privacy removes the Orientation tag along with the GPS coordinates, so every viewer falls back to the raw pixel data — and if those pixels were sideways, the photo is now permanently sideways everywhere. Always apply the rotation to the pixels before stripping metadata.
How do I fix orientation without losing quality?
Use a lossless JPEG rotation, which rearranges the compressed 8x8 blocks without decoding and re-encoding. The jpegtran utility does this with -rotate, and several image tools offer it as 'lossless rotate'. Rotating in a normal editor and re-saving re-compresses the whole image and loses a little quality every time.