--
title: "HEIC vs JPG: A Developer's Guide to the iPhone Photo Format Problem"
description: "HEIC vs JPG: A Developer's Guide to the iPhone Photo Format Problem"
tags: ["photography", "webdev", "apple", "tips"]
canonical_url: https://image-compressor-saas.shop/blog/heic-vs-jpg-iphone-photos
Last year I pulled about 3,000 photos off an iPhone onto a Windows machine and a third of them wouldn't open. The machine wasn't broken. The format was HEIC, and Windows doesn't natively decode it. This is the same wall most web devs hit when a user uploads "a photo" and it arrives as an opaque blob.
Here's the technical picture. HEIC is the container for High Efficiency Image Coding, built on the HEIF standard, and Apple made it the default on iOS 11. The codec is newer and much more efficient than JPEG: for the same visible quality, a HEIC file typically lands around half the size of an equivalent JPG. For a 12-megapixel photo that's roughly 2-3MB versus 4-6MB. Over 10,000 photos a year that's tens of gigabytes of storage difference, which is exactly why Apple bet on it.
But efficiency is only half the story, the other half is decoding support. HEIC is well supported inside Apple's ecosystem and poorly supported everywhere else. Windows Explorer needs a plugin. Many browser pipelines, older printer drivers, and photo lab systems don't recognize it. Android devices and a long tail of web apps have no native HEIC path at all. So the moment a file leaves the Apple ecosystem, "efficient format" becomes "incompatible format."
From a web dev perspective, the practical rule is simple: your upload pipeline should treat HEIC as an input to convert, never as a final deliverable. Most job portals, visa applications, and e-commerce platforms accept JPG or PNG only, and the user will be stuck at your upload step if you don't handle the conversion. Sending to a non-Apple user means expecting a gray block or a garbled filename on their side.
The conversion itself is a single decode plus re-encode, so it's cheap. Two things matter for quality. A proper converter decodes the HEIC and re-encodes as JPG in one pass, which means one compression with theoretically slight loss that's invisible at normal viewing distances. The failure mode is double compression, converting to JPG and then compressing the JPG again, which is when things go mushy. Always convert from the original HEIC, never from a previously compressed JPG.
Architecture-wise, the pattern I use is: keep HEIC originals on-device and in iCloud, and convert to JPG at the boundary whenever a file goes out. That boundary is the exact spot to hook a converter, and it's the pattern that keeps storage savings without leaking compatibility problems downstream.
On the storage-versus-compatibility tradeoff, this is the same argument that has played out with WebP and AVIF: newer formats win on efficiency, older ones win on universality, and the correct answer is almost always "convert at the boundary" rather than "pick one forever."
If you need a quick JPG on the spot, your pipeline can reuse the HEIC's decode data instead of re-encoding from a compressed image. That's the difference between a decent converter and a blurry one. The format comparison and converter notes are here: https://image-compressor-saas.shop/blog/heic-vs-jpg-iphone-photos-guide
