EXIF orientation, and the photo that shows up sideways
A photograph can be upright in one program and sideways in the next, because the uprightness is not in the pixels but in a note that gets thrown away.
There is a particular annoyance in sending somebody a photograph and hearing back that it arrived on its side. It is upright in the folder you dragged it from and wrong in the one place that matters, which is the upload box at the other end.
The disagreement is not random and it is not damage. Uprightness is not in the pixels. It lives in a note attached to them, and the program showing the picture lying down never read the note.
The sensor is held one way and mounted another
A sensor is a fixed rectangle of light-sensitive cells inside a body that a hand turns in every direction. The grid never moves: row one is always the edge nearest the same corner of the case. So the pixels come off it in the sensor's idea of up, which is not necessarily yours.
A phone makes this awkward. It is built to be held in portrait and pointed at a mostly horizontal world, and its sensor is mounted to match the body, so an upright frame arrives as a grid whose width and height sit the wrong way round relative to the scene.
Rotating those pixels means moving every value in the buffer to a new address. A twelve-megapixel frame is 4032 × 3024, which is 12,192,768 pixels, and at three bytes for each colour pixel that is 36,578,304 bytes, a little under 35 MiB, read and written again before the encoder has started. Every shot in a burst pays it.
So the firmware takes the cheaper route. It writes the pixels as the sensor saw them and attaches a note saying, in effect, turn this a quarter turn clockwise before you show it to anyone. The note is a field called Orientation, tag 0x0112, in the EXIF block that every JPEG carries. A viewer that reads it draws the picture upright. One that ignores it draws it sideways.
What the tag is allowed to say
The field holds a small integer, and each value names a transformation. Reflections are in the list because two real situations produce a mirrored frame: film scanned from the wrong side of the sheet, and front cameras that mirror the preview so it behaves like a mirror.
| Value | What it means | Where you meet it |
|---|---|---|
| 1 | No transformation. The pixels are already upright. | The default, and what most files carry after an editor |
| 3 | Rotate 180 degrees for display. | A camera held upside down, or a scanner fed the sheet the other way |
| 6 | Rotate 90 degrees clockwise for display. | The common phone case: shot upright in portrait, sensor mounted for landscape |
| 8 | Rotate 90 degrees counter-clockwise for display. | The other portrait case, body turned the opposite way |
| 2, 4, 5, 7 | Include a reflection as well as a rotation, so turning the image cannot reach them. | Scanned film from the reverse side, and mirrored output from some front cameras |
Values 1, 6 and 8 cover the overwhelming majority of files you will handle, because they are what a phone writes. The reflected family is rare enough to treat as a curiosity.
Notice what the tag does not say. It does not record which way is up in the scene, only how to turn the stored grid so that it looks correct, which is why a file can be right while its display is wrong.
Why the instruction goes missing
Metadata is not part of the picture, and plenty of programs treat it as baggage. Some are careful: a service that publishes at scale re-encodes on arrival and drops the block so a stranger's home coordinates do not end up in a public image. Some are merely optimising: a resizer decodes the picture, draws it at a new size, and writes a fresh file with new pixels and no header.
Careful and careless end the same way for the rotation. A GIF export, a screenshot pipeline, an editor that re-encodes on save, a thumbnail generator on a server: any of them can leave a file whose pixels are sideways and whose instruction has been dropped. On the machine that did the processing everything looks right.
The opposite failure is worse, because it looks like the tool being broken rather than forgetful. Rotate the pixels and keep the tag, and the next reader turns the picture a second time. A portrait frame at value 6 with an untouched tag comes back half a turn out.
Browsers read the tag by default now, which is why a file straight off a camera roll looks right on a page, and why the problem stays invisible until you look at it somewhere else.
The fix is to bake the rotation in
Turning the pixels so that the file is upright by construction is the only answer that survives every downstream tool. Once the grid is correct and the tag says nothing needs doing, the picture is right for anything that can open a JPEG.
A file straight off a camera roll commonly announces its own rotation, and a metadata reader prints it plainly:
Orientation : Rotate 90 CW
GPS Latitude : 51 deg 30' 12.60" N
GPS Longitude : 0 deg 7' 39.60" WThe first line is the instruction: turn the grid a quarter turn clockwise and the picture sits up. The next two lines are where the phone was standing when the shutter fired, and they matter more.
The rotation is one command in most image tools. ImageMagick spells it -auto-orient: read the tag, turn the pixels to match, and rewrite the entry to 1 so that nobody turns them again. Skipping that last part builds the double rotation above.
The cost is a re-encode. A JPEG decoded and written back out is a second generation: the encoder re-quantises detail that was already quantised once, so the second version is measurably worse than the first at the same quality setting. File size moves a few percent either way, because the dimensions have swapped and the encoder's decisions are not symmetric.
There is one honest exception. A JPEG stores its pixels as blocks of frequency coefficients, and a quarter turn maps each block onto another block, so the rotation can be done by moving blocks without decoding anything. The tool is called jpegtran, and it applies only when the width and height are multiples of the block size.
The note does not travel alone
The orientation field is one entry in the EXIF block, a small directory of everything the camera knew at the moment of capture. Some of it is harmless and interesting: the exposure time, the aperture, the lens, the make and model. Some of it is neither.
| Field | What it holds | What it gives away |
|---|---|---|
| Make and Model | The manufacturer, and the body or handset | Which device took the picture |
| DateTimeOriginal | The moment the shutter fired, to the second | When you were there, and when you were not at home |
| GPSLatitude, GPSLongitude | The position fix, to several decimal places | Where the camera was: a degree of latitude is about 111 km, so the fifth decimal place is about a metre |
| GPSAltitude, GPSDateStamp | Height, and the UTC date of the fix | A second witness to the same location, in fields people forget |
| Software | The application that last wrote the file | Which editor produced this version |
| Embedded thumbnail | A small JPEG of the whole frame, written at capture time | Possibly the original of a picture you cropped later |
The location row is the one to think about before publishing a photograph of a room, a pet or a receipt. A picture taken on a kitchen table carries the address of the kitchen.
The thumbnail row catches people who are otherwise careful. Cropping a photograph to remove a face, a number plate or a document on the desk does not remove it from the thumbnail, because the thumbnail is a separate image.
The order of operations
Read the tag. Apply the rotation. Strip the block. That is the order, and it is the order because the first step is the only thing that tells you what the second one should do.
Done the other way round, the information you needed is gone. Strip first and the pixels lie sideways with nothing to say by how much, leaving you to guess whether the fix is one quarter turn or three.
A tool that removes metadata and a tool that rotates are separate operations, and a tool offering both should be asked which order it uses. Reading the tag, applying it, then writing the file without the block is right.
Where the tools fit. The Image Resizer redraws the picture into a new pixel grid, and to do that the browser has already applied the orientation while decoding, so the file that comes out is upright by construction with no tag left for anything to misread. The Image Compressor works the same way from the other direction, re-encoding for weight rather than size, and writes a fresh header, so the location block that arrived with the camera file is not in what leaves.
Put a file through either tool, then open the result in the oldest viewer you own.
What the block weighs
Metadata is not why a file is heavy. The EXIF directory is a few hundred bytes of tag names and values, plus whatever maker note the manufacturer included, usually a kilobyte or two. Against a four-megabyte photograph that is nothing worth measuring.
The embedded thumbnail is the part with a number worth checking. It is a real JPEG of the whole frame, commonly a little over a hundred pixels on its long edge, and on some cameras it costs tens of kilobytes. On that photograph it is rounding error. On an image optimised for a page and weighing 30 KB, an 8 KB thumbnail is more than a quarter of the file.
So the size argument is real but narrow. Drop the block for privacy, and take the saving as a side effect on files small enough for it to show.
The habit I would keep
For a photograph headed for a page, a post or a message: bake the rotation in, then drop the location. The picture is then correct in any program that can open a JPEG, and the coordinate is not inside it.
For a photograph you are keeping, keep everything. The timestamp and the coordinates are the only durable record of when and where it was taken, and the day comes when you want to know which trip a folder belongs to.
The habit worth building is a check. Before a file leaves your hands for a public place, ask what it carries: open the properties, or put it through a metadata reader, and look at the orientation value and the coordinate pair. An orientation value other than 1 means the picture depends on somebody else's software to hold it upright. A coordinate pair means deciding whether you meant to publish the location as well.