
It's a pattern that shows up every application season: a form asks for a photo, someone picks a picture straight off their iPhone, and the site answers "unsupported file type". Or the upload bar finishes and the preview is a broken-image icon. The photo opens fine on the phone, so it's not obvious what went wrong. In most of these cases the file is HEIC, not JPEG, and converting it to JPG fixes the upload. The part that trips people up afterwards is that the converted JPG can end up bigger than the original.
How to tell it's HEIC
HEIC is the default photo format on iPhones since iOS 11. It stores the same picture in fewer bytes than JPEG, using HEVC compression. Look at the file extension: .heic or .HEIC. Windows hides extensions by default (File Explorer → View → File name extensions); on a Mac, Get Info shows the kind as "HEIF Image". Apple's documentation also says photos may be converted to JPEG when transferred to a Mac or PC, unless Settings → Apps → Photos → Transfer to Mac or PC is set to "Keep Originals". That's why two people with the same phone can have different results.
Why other machines and browsers can't show it
A viewer needs a decoder for the format. Apple ships one in iOS and macOS. On Windows, Microsoft says you need both the "HEIF Image Extensions" and the "HEVC Video Extensions" from the Store, and the HEVC one may be paid.
For browsers, I tested a sample rather than guessing. I didn't have a shareable iPhone original, so I took a CC0 photo from Wikimedia Commons that was shot on an iPhone 6 and encoded it to HEIC with macOS's built-in sips. So it is not a straight-from-camera file, though it has the same 512×512 tile-grid layout and rotation property iPhone photos use. In the browser engines bundled with Playwright on macOS 26.5:
- Chromium 149:
<img>fails,createImageBitmapthrows - Firefox 151: same failure
- WebKit 26.5: displays, 2448×3264, correct orientation
WebKit works because it leans on the macOS system decoder. I didn't test real Safari, Windows, or phones. But if a form tries to preview or measure the image in a Chromium-based browser, it has nothing to work with.
Converting to JPG
On a Mac, Preview's File → Export to JPEG works, and sips -s format jpeg x.heic --out out/ does several files at once. One detail: the sips output keeps the pixels landscape (3264×2448) and writes EXIF Orientation 6, relying on the viewer to rotate it.
Without a Mac, a browser-based converter avoids installing Store extensions. I used imging with the same sample. The first time you open a HEIC it can't decode it natively, so there's a "Load decoder" button. That downloads a WASM decoder built on libheif; the photo itself stays in the browser.
Two things to watch. Before loading, the bottom bar says "Server processing required"; after loading it changes to "Instant processing · Runs in your browser; the source image is never uploaded". And WebP is preselected, which most upload forms reject, so click JPG before "Convert & Download". It takes one file at a time.
Check size and orientation before uploading
The portrait sample was 745.1 KB. At the default quality of 88 the JPG came out at 1.01 MB, 38% larger. That makes sense, since HEIC compresses better than JPEG. If the form caps uploads at 1 MB, drop quality to 80: the same photo became 742.2 KB. A 4032×3024 version went from 840.1 KB to 1.32 MB at quality 88 (+61%) and 982.9 KB at 80 (+17%).
For orientation, imging's output was 2448×3264 with Orientation set to 1, so the pixels are already upright. With tools that only set the EXIF flag, a system that ignores EXIF could show a portrait photo sideways. I haven't tested any upload systems for that, so I just open the file and look before uploading.
So it doesn't happen again
Settings → Camera → Formats → Most Compatible. Apple says new photos will then be saved as JPEG (and videos as H.264). Existing photos stay HEIC, so you'll still need to convert those.
The converter I used is at https://imging.ai/

Top comments (0)