Rotate HEIF images online for free. Fix sideways iPhone and Samsung photos; the result is saved as JPG.
HEIF (High Efficiency Image File Format, ISO/IEC 23008-12) is the modern image container Apple adopted as the default iPhone format in iOS 11 / 2017 and Samsung uses on Galaxy phones. HEIF stores orientation as both an internal irot transformation property and an EXIF Orientation tag — and when those two disagree, different apps render the image differently. The cleanest fix is to bake rotation into the pixel data and clear the orientation tag so every viewer agrees. Common reasons to rotate:
irot (HEIF spec) and EXIF Orientation. Some editors update one and not the other, producing files that look correct in Apple Preview but flipped in Chrome, Firefox, or Pillow-based pipelines. See libheif issue #227 for the canonical write-up.| Property | HEIF | HEIC | JPEG |
|---|---|---|---|
| Spec | ISO/IEC 23008-12 (container) | Apple's HEIF + HEVC variant | ISO/IEC 10918-1 |
| Rotation mechanism | irot property + optional EXIF tag |
Same as HEIF | EXIF Orientation tag only |
| Default extension | .heif, .heifs |
.heic |
.jpg, .jpeg |
| Apple support | iOS 11+, macOS High Sierra+ | Same | All versions |
| Web browser native render | Safari 17+, partial Chrome via flag | Safari 17+ | Universal since the 1990s |
| Typical file size vs JPEG (same quality) | ~50% | ~50% | 100% (baseline) |
If a recipient can't open HEIF, convert HEIF to JPG — JPEG renders everywhere but is roughly twice the size at the same visible quality.
| Angle | When to use | Quality cost |
|---|---|---|
| 90° CW / 90° CCW | Portrait shot saved as landscape (or vice versa) | No interpolation; small re-encode loss when saved |
| 180° | Photo taken upside-down or scanned the wrong way | No interpolation; small re-encode loss when saved |
| "Fine angle" (−45° to 45°, add a quarter turn for more) | Straightening a tilted horizon, correcting drone roll | Minor resampling; corners filled or trimmed ("Auto-crop corners") |
90°, 180°, and 270° rotations involve no interpolation, but the result is still re-encoded — as JPG, since a browser cannot write HEIF. Custom angles require interpolation, so re-rotating multiple times stacks small quality losses — do all rotation in one pass.
Apple's Photos and Preview apps read both the irot HEIF property and the EXIF Orientation tag, and they apply the rotation visually before display. Many other viewers (Chrome's HEIF preview, libheif-based pipelines, older versions of Pillow) only read one or the other — or read both and apply both, resulting in double-rotation. Rotating with XConvert bakes the orientation into the pixel data and resets the EXIF Orientation tag to 1, so every viewer renders the image the same way.
Only slightly. A browser cannot write HEIF, so every rotation is saved as a new image in the format the Download button names (usually JPG); 90°, 180° and 270° turns move pixels without resampling, and at the default "Quality" of 85 the re-encode loss is invisible to the eye. Save as PNG for a lossless copy of the rotated pixels. For custom angles (e.g., straightening a 3° tilt), the image is resampled (bilinear interpolation) and re-encoded, which is visually lossless at default quality but technically a re-encode. If you'll rotate multiple times (e.g., crop, then rotate, then crop again), do everything in one session to avoid stacking losses.
The still image is rotated and re-saved. Live Photo motion clips (the paired.MOV) and depth/Portrait data are stored as separate streams and are NOT preserved on download — the editor outputs a single still image, JPG unless you pick another format (a browser cannot write HEIF). If you need those auxiliary streams intact, edit the photo in iOS Photos directly (which keeps Live Photo and depth) and let it bake the rotation on export.
Several possibilities: (1) a service stripped EXIF metadata during upload (Reddit, Discord, many web forms strip EXIF for privacy); (2) the file went through a converter that copied EXIF Orientation but didn't apply the irot transformation, causing one or the other to be ignored; (3) you opened it on macOS Sonoma 14+, which changed how HEIF orientation is interpreted from earlier macOS versions. The fix is the same: rebake the rotation into the pixel data.
Yes. Samsung Galaxy phones write HEIF using the same ISO/IEC 23008-12 container as iPhone HEIC (they're the same standard, different vendor extensions). XConvert handles both. The orientation conflict is identical because both Apple and Samsung write irot and EXIF Orientation tags into the same file.
HEIC is Apple's brand name for HEIF using HEVC compression — same container, same rotation mechanics. If your file extension is .heic, use the HEIC rotation tool for clarity; if it's .heif or .heifs, use this page. The actual rotation operation and output are equivalent.
Yes — drop up to 50 HEIF files at once (a mixed batch works too). The rotation angle you set applies to every file in the batch; "Download all (.zip)" saves every rotated result in one ZIP, or use "Download one by one" to save them separately.
It becomes JPG unless you pick another format: a browser cannot write HEIF, so the editor has no HEIF output. JPG opens for Android users on older OS, in legacy document formats, on platforms that reject HEIF and at printers that don't accept HEIF natively; pick PNG with "Save as" for a lossless copy. JPG is universal but ~2× larger than the HEIF; PNG is lossless but 3-5× larger. If your audience is all iPhone, iPad and modern Mac and the file must stay HEIF, rotate it in the Photos app instead. For HEIFs you are not rotating, HEIF to JPG and HEIF to PNG do the conversion alone.
Yes. Resize, Crop, Rotate and Flip are tabs of the same editor: open Resize to set a width, height, percent or "Size preset", or Crop for aspect-ratio chips and platform sizes, before you download, and the photo is encoded once. The HEIF cropper opens the same editor on its Crop tab. To shrink file size further after rotating, see the HEIF compressor.