2026-07-31

Why your photo looks sideways in one place and fine in another — and how to fix it for good

The same photo can look perfectly upright when you open it one place and land on its side somewhere else — same file, no edits in between. It feels random, but it isn't. There's a specific piece of metadata behind it, a specific reason some tools respect it and others don't, and a specific reason running a photo through NearIMG fixes it permanently instead of just moving the problem somewhere else.

Cameras don't actually rotate the pixels — they leave a note

When you turn your phone sideways to shoot a landscape photo, the camera sensor doesn't physically rotate. It always reads out pixels in the same fixed orientation relative to the sensor. Instead of re-arranging every pixel before saving, the camera writes a single flag into the file's EXIF metadata — the Orientation tag — recording how the image needs to be turned to look right. It's a cheap, instant way to record "this needs a 90° turn" without re-encoding the whole photo on the spot. The catch is that this only works if whatever opens the file later actually reads that tag.

Why the same file behaves differently in different places

This part is genuinely inconsistent, and there's a real, checkable reason why. On the web specifically, this stopped being a coin flip a while ago: the CSS image-orientation property's initial value is from-image, and per MDN it's been Baseline — "widely available" across major browsers — since April 2020, with the spec describing exactly what it does: "the EXIF information contained in the image is used to rotate the image appropriately." The JavaScript-level decoder browsers use, createImageBitmap(), defaults to the same behavior — its imageOrientation option defaults to from-image, meaning "image oriented according to EXIF orientation metadata, if present." So opening a photo directly in a current browser or a modern photo viewer is, by now, usually fine.

Backend tools are a different story, and this is where a lot of "it looked fine when I took it, sideways after the site processed it" cases actually come from. Python's Pillow — one of the most widely used image libraries for exactly this kind of server-side resizing — does not apply EXIF orientation automatically when you open a file. Its own documentation is specific about what fixes it: ImageOps.exif_transpose(), which "if an image has an EXIF Orientation tag, other than 1, transpose[s] the image accordingly, and remove[s] the orientation data." That's a function you have to know exists and remember to call — Image.open() by itself won't do it. A lot of upload pipelines, thumbnail generators, and quick resize scripts are built on exactly this library, and skip that one extra line.

The quieter cause: the tag gets deleted, not corrected

There's a second, less obvious way this happens even outside any of the above. Plenty of tools — privacy-conscious upload forms, some image optimizers, generic "strip metadata" utilities — remove EXIF data on purpose, usually for a good reason (EXIF can carry GPS coordinates and other information people don't want attached to a public photo). If that stripping happens without first transposing the pixels to match what the Orientation tag said, the correction gets deleted along with the tag, and the photo reverts to however the sensor actually recorded it — sideways, if that's what it was.

What actually happens when a photo goes through NearIMG

This is the part that's specific to how NearIMG is actually built, not a general claim about "any online tool": every image that isn't HEIC gets decoded through the browser's own createImageBitmap(), with no override to the imageOrientation option — so the browser's default (from-image) applies automatically, before a single NearIMG tool runs. That means the bitmap NearIMG is working with already has its pixels in the visually correct orientation.

From there, every tool in this post's scope — Compress, Resize, Crop, Rotate, and any JPG/PNG/WebP format conversion — runs the same way under the hood: draw onto a fresh canvas, then encode with canvas.convertToBlob({ type, quality }). That method's only two options are the output format and the compression quality — there's no parameter for carrying metadata across, EXIF included. The practical result: the file NearIMG hands back doesn't have a correct orientation tag that some future app might ignore — it has correct pixels, full stop, with no tag to depend on at all. Running a photo through any one of those tools once is enough; the fix is permanent from that point forward, regardless of what opens the file next.

Depending on an EXIF tag means the same file can look different in different apps. NearIMG bakes the correct orientation into the pixels themselves, so there's no tag left for anything downstream to get wrong.

When you still need the Rotate tool

None of this helps if the correct orientation was never recoverable in the first place — for example, a photo whose metadata was already stripped by something upstream before you ever got the file, with no Orientation tag left to read at decode time. In that case there's nothing for from-image to work from, and the photo will decode however its pixels are actually laid out. That's exactly the case NearIMG's Rotate tool is for: a manual, one-click 90° turn (with 180°/270° available the same way) to fix a photo no automatic step could have caught.

Honest limits

Rotate moves in fixed 90° steps, not arbitrary angles. It fixes a photo that's turned a quarter- or half-turn the wrong way. It won't level a horizon that's tilted a few degrees off — that's a straightening problem, not an orientation problem, and a different kind of fix.
This is about JPEG-style EXIF orientation specifically. The behavior described here — a decoder defaulting to from-image, an encoder that drops metadata entirely — is what was verified against the browser APIs NearIMG actually calls. HEIC files use their own, separate metadata mechanism, covered by a different post rather than assumed here.
If the pixels themselves are wrong with no tag to correct them, no software can guess the right answer automatically — including NearIMG's own automatic decode step. That's not a gap anything can quietly close; it's exactly why a manual Rotate button still needs to exist.

The short version

A "sideways" photo almost always isn't damaged — it's a pixel grid the camera never physically rotated, paired with an EXIF tag that says how to display it, read correctly by some software and ignored or discarded by other software. Modern browsers handle this automatically now; plenty of backend resizing pipelines, built on tools that don't, still don't. Passing a photo through any of NearIMG's Compress, Resize, Crop, Rotate, or format-conversion tools decodes it with that tag already applied and re-encodes it with no tag left to lose — the fix stops being conditional on whatever opens the file next.