Images & photos · Browser Image & Drawing Editor
How browsers handle EXIF orientation when you edit a phone photo
· How it works
image-editing canvas browser-processing
Phones often save photos sideways and rely on a tiny orientation tag to tell viewers how to rotate them. This post explains what that tag is, how the browser applies it during decoding, and why an edited export no longer needs it.
The photo that is upright on your phone and sideways everywhere else — the concrete symptom and the eight-value EXIF Orientation tag behind it
Start with the symptom: a portrait that looks upright in the phone gallery can arrive sideways in another viewer. EXIF Orientation is an instruction attached to the file, with eight possible values describing flips and quarter-turns. The useful evidence here is narrower than a general browser promise: this editor loads an HTML Image from a scoped object URL, draws the decoded result, and has no fixture proving how every browser handles every orientation value.
Use a copied phone photo as the test specimen. Record its displayed dimensions, make a small crop, export it, and open the download in a second viewer. Canvas export re-encodes the displayed pixels through canvas.toBlob as PNG, JPEG, or WebP; it does not copy the source container or promise to retain EXIF. The comparison tells you what happened to this raster, not what every file will do.
A sideways result is possible, but this repository does not parse the eight EXIF orientation values
The mismatch exists because a camera can record sensor rows in a convenient physical order while storing a compact instruction about how those rows should be presented. Treat that explanation as context, not as a claim about this application. The repository does not parse the eight EXIF Orientation values, and it does not prove which browser versions apply them before the image reaches the canvas.
That limitation changes the practical workflow. Keep the original untouched, open a duplicate, and judge the decoded appearance rather than assuming the tag has been interpreted correctly. The editor can rotate the whole raster in ninety-degree steps, but it cannot edit or restore orientation metadata. An export is therefore a new pixel result whose behaviour should be checked in the viewer that matters to you.
Camera storage rationale is outside repository evidence; inspect the actual decoded result
A browser may decode an image with an orientation instruction already reflected in the rendered pixels. Modern APIs can expose decoding choices, including createImageBitmap options, but this code path does not call createImageBitmap or set an imageOrientation option. It creates an HTML Image from an object URL and draws that image, so the actual phone file and browser remain part of the experiment.
Inspect the result at two stages: first in the editor, then after export. Note both the apparent portrait direction and the width and height reported by the document. If the first view is wrong, a manual quarter-turn can make the working raster look right. If the first view is right, avoid claiming that the original metadata was understood universally; the repository evidence supports only the observed decoded result.
This editor loads an HTML Image and sets no explicit orientation-decoding option
Once pixels pass through a canvas and are encoded again, the source container is no longer the object being delivered. The editor composites decoded pixels with your crop and any other visible edits, then calls canvas.toBlob for PNG, JPEG, or WebP output. That process does not promise to preserve EXIF fields. In particular, this implementation cannot edit or restore an orientation tag for a later viewer to interpret.
The safest description of the download is an image that contains the pixels produced by this editing session. Reopen it in another viewer and check the direction before sharing it. If that viewer agrees, you have verified one concrete export. You have not certified all EXIF behaviour, but you have replaced an ambiguous metadata instruction with a testable raster result for this file.
Canvas export re-encodes displayed pixels but does not certify which metadata fields remain
Consider a portrait phone photo intended for a message. Open a duplicate, observe whether the editor displays the person upright, and note the decoded dimensions before cropping. If the scene is sideways, rotate the raster in ninety-degree steps until the working image is visibly correct, then crop only after that correction. The operation is a pixel edit, not a repair to the file metadata.
Export the crop and compare it with the editor view in a second image viewer. PNG, JPEG, and WebP are produced from the canvas, so the output is a re-encoded image rather than the original phone container. Record the format and viewer used if the result matters operationally. That small audit gives you evidence about this portrait, while avoiding an unsupported promise about every phone or browser.
Worked check: compare decoded dimensions and appearance before cropping and exporting
There are clear boundaries around this investigation. The editor does not provide a metadata inspector, an EXIF editor, or a tool for restoring the original Orientation value. It also cannot make a viewer that ignores orientation metadata behave correctly. Those jobs belong to software designed to preserve or rewrite image containers, not to a canvas workflow whose output is a flattened raster.
The same caution applies to other EXIF fields such as capture time, location, and camera details. Canvas export composites decoded pixels through canvas.toBlob and does not certify which metadata fields remain. Keep the original if those fields matter, use the editor for the visible image work, and verify the exported file before treating it as a metadata-preserving replacement.
Takeaway: edit once, upright everywhere — how editing in the Browser Image & Drawing Editor produces a file that displays the same in every viewer
The practical takeaway is simple but deliberately limited: edit the visible raster, then verify the exported orientation in another viewer. The Browser Image & Drawing Editor is useful for opening a local phone photo, rotating the whole raster in ninety-degree steps, cropping it, and producing a PNG, JPEG, or WebP download. Its loader and export path do not justify a claim of universal EXIF handling.
A reliable check takes less than a minute. Keep the source, open a copy, record the initial direction and dimensions, make one small edit, export once, and inspect the download elsewhere. If the file is wrong, return to the copy and correct the pixels manually; do not assume the orientation tag can be restored here. The verified result is the file you actually opened and checked.