Reference · dataset of function(){throw Error("Attempted to call COMPAT_VERSION() from the server but COMPAT_VERSION is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.")}
Orientation compatibility
A photo that is upright in one place and sideways in another has an orientation tag that one program reads and the other ignores. Which repair to use depends on where the file is going: if the destination reads the tag, rewriting the tag is enough; if it ignores it, only turning the pixels themselves works. This table is the record of what each destination does, and — just as important — how that is known.
How each row is known
- Tested: somebody here opened the test file at that destination and wrote down what it showed, with the date and the method. A tested row older than 180 days says “not recently verified”.
- Documented: the behaviour is published by the vendor or is well established, but has not been tested here.
- True by construction: it follows from how the destination works (a program that drops metadata cannot read a tag).
- Untested: nobody here knows yet. These rows are shown, not left out, and the repair advice for them is the safe one.
The test file: orient6.jpg — a landscape array stored with EXIF Orientation 6, which a tag-reading program shows as a portrait.
The table
| Where it is going | The tag | How it is known |
|---|---|---|
| Browsers | ||
| Chrome and Edge (Chromium), picture on a web pageThe picture is shown turned by its tag, both in an <img> element and as a CSS background.Method: A 60 × 40 JPEG (left half red, right half blue) tagged 6, shown in an <img> element and as a CSS background; the displayed size and pixel colours were read back: 40 × 60, red on top — turned as the tag says. (RotatePictures build check (headless Chromium 153)) | Reads the tag | Tested 24 Oct 2026 |
| Firefox, picture on a web pageDocumented behaviour: the CSS default image-orientation: from-image has applied the tag since 2020. | Reads the tag | Documented, not tested here |
| Safari (macOS and iOS), picture on a web pageDocumented behaviour: applies the tag to images by default. | Reads the tag | Documented, not tested here |
| Phones and computers | ||
| Windows Photos and File Explorer thumbnailsDocumented behaviour of camera-oriented viewers: the tag is applied before showing. A stale embedded thumbnail can still show the old way round in Explorer. | Reads the tag | Documented, not tested here |
| macOS Finder and PreviewDocumented behaviour: the tag is applied before showing. | Reads the tag | Documented, not tested here |
| Android gallery appsDocumented behaviour of camera apps' own galleries; third-party galleries vary. | Reads the tag | Documented, not tested here |
| Messaging and mail | ||
| WhatsApp (phone app and WhatsApp Web)Phone apps are reported to apply the tag; some desktop and web paths historically did not. Not tested here yet. | Not known yet | Untested |
| Gmail attachment previewNot tested here yet. | Not known yet | Untested |
| Instagram uploadNot tested here yet. Instagram stores pictures at up to 1080 px wide; bake the orientation before posting from a desktop browser. | Not known yet | Untested |
| Older email clients and message previewsDocumented behaviour: frequently draw the stored grid directly, so the recipient sees the sideways version. | Ignores the tag | Documented, not tested here |
| Portals and documents | ||
| A recruitment portal's upload previewPortals differ, and many resize uploads on the server with software that ignores the tag. Not tested here yet. | Not known yet | Untested |
| A bank KYC upload previewNot tested here yet. | Not known yet | Untested |
| DigiLocker document previewNot tested here yet. | Not known yet | Untested |
| Upload forms that make their own thumbnailDocumented behaviour: the tag survives or not depending on what resized the file on the way in. The commonest place a photograph arrives on its side. | Sometimes | Documented, not tested here |
| PDF builders, print layouts and office suitesDocumented behaviour: most place the stored sample grid and never look at the tag, so a turned file goes into the document turned. | Ignores the tag | Documented, not tested here |
| Anything that re-encodes without copying metadataBy construction: if the tag is dropped and the pixels were never turned, the correction is lost for good. Baking the turn into the pixels survives this. | Ignores the tag | True by construction |
The safe default
When in doubt, bake: turn the pixels and leave no tag. Every decoder, tag-reading or not, shows a baked file the same way. Rewriting the tag only is better where it is enough — it changes two bytes and leaves the picture data untouched — but that is only true at destinations known to read the tag. The fix orientation page offers both and lets you pick the destination to see which one it needs. Why the disagreement exists at all is in why photos turn sideways online.