The choice has been sitting in your camera’s menu for a few years now — somewhere between white balance and autofocus modes — and most photographers leave it on JPEG and move on. HEIF (High Efficiency Image Format) was developed by MPEG and ratified by ISO in 2015, and the theoretical case for it is genuinely strong. Smaller files at comparable perceptual quality. Higher color depth. Wider color gamuts. So why hasn’t it quietly replaced JPEG the way HEVC slowly displaced H.264 in video? Because format compatibility is not a theoretical problem — it’s a practical one that hits you at the worst moment, usually when a client or print lab is on the other end of a file transfer.
This article is about what actually changes at the file level when you switch, where that matters, and where it probably doesn’t yet.
What HEIF Actually Does Differently
JPEG has used the same core compression method since its original 1992 specification: Discrete Cosine Transform (DCT) applied in 8×8 pixel blocks, with quantization tables that determine how aggressively frequency information gets discarded. The result is the familiar grid of blocking artifacts at high compression. The JPEG specification technically defines extended and lossless modes beyond 8 bits, but they’re rarely implemented — ordinary camera JPEG output, browser-rendered JPEG, and mainstream JPEG editing workflows are, in practice, all 8 bits per channel. That’s the ceiling you’ll actually run into day to day, even if it isn’t a universal limit of the spec itself.
HEIF is a container format — it can technically wrap multiple codecs, but in practice it almost always contains images encoded with HEVC (H.265). HEVC uses a more sophisticated approach than baseline JPEG: variable-sized coding units (as small as 8×8, scaling up to a 64×64 coding tree unit) and more advanced entropy coding, both of which let it discard less visible detail at a given file size. HEIF’s container format also supports storing multiple related images — bursts, depth maps, or an image sequence — inside a single file, which is a real capability of the format itself, worth keeping separate from how any one company chooses to use it. That distinction matters on iPhones specifically: an Apple Live Photo is not simply “a HEIF burst” sharing redundant image data. Apple documents Live Photo export as producing a separate still image and a short paired video file, not a single multi-image HEIF container. For a still camera, the coding-unit and entropy-coding improvements above are the part that actually applies to your files.
The upshot: HEIF can, in a lot of cases, deliver comparable visual quality to JPEG at a meaningfully smaller file size — that’s a real property of HEVC-based encoding, not marketing language. How much smaller varies considerably, though, since it depends on the specific encoder, the image content, and the quality settings used on each side of the comparison — there’s no fixed percentage worth quoting as a constant. As a general pattern, the size advantage tends to narrow on flat, low-detail images and widen on scenes with fine texture — grass, fabric, detailed foliage — which is exactly where DCT blocking artifacts in JPEG show up first.
Beyond compression efficiency, the format supports:
- 10-bit (and higher) color depth — mainstream JPEG output is limited to 8 bits per channel, which is part of why HDR display pipelines have moved toward other formats
- Wide color gamuts (Display P3, Rec. 2020) without gamma encoding hacks
- Alpha channel transparency — JPEG has none; HEIF handles it natively
- Multiple images in one file — cover image, burst sequence, depth maps, and gain maps (used in Apple’s Adaptive HDR photo pipeline) can all live in a single .heic or .heif file
- Lossless compression as an option, though few cameras expose it that way
For still camera photographers, the immediately relevant benefits are higher bit depth and compression efficiency. If your camera also shoots video in HDR, the overlap with HEVC becomes an argument for format consistency in your asset library.
Where Compatibility Actually Breaks Down
This is the part that matters more than the spec sheet. JPEG has universal support — every device, every browser, every print lab, every social platform, every word processor. HEIF has decent and improving support, but with enough rough edges that they’ll still catch you off guard.
Operating system support is solid on macOS (since High Sierra, 2017) and iOS, decent on Windows 10 version 1803 and later with the correct Microsoft HEIF Image Extensions installed, and inconsistent on Linux depending on the distribution and version. Android support improved significantly at Android 9, but varies by manufacturer skin.
Browser support is where the gaps are sharpest, and it’s worth being precise about the current state rather than assuming it’s improved over time. As of this writing (mid-2026), Safari is the only major browser that displays HEIF/HEIC images natively, and it has since Safari 17. Chrome, Edge, and Firefox do not natively decode and display HEIF/HEIC images — dropping a .heic file into a web page will not render in any of those browsers, regardless of what the underlying operating system itself can do with the file. Browser vendors do periodically revisit format support, so check a current compatibility reference like caniuse.com before relying on this for a new project rather than trusting any single article, including this one, indefinitely. In practice, this means: if you export HEIF files for direct web use without converting them to JPEG or WebP first, most visitors on non-Safari browsers will see a broken image rather than your photo.
Print lab and client workflows are the strongest practical argument for staying on JPEG, or at minimum converting before you deliver. Much lab-side RIP software is built around JPEG and TIFF input, and HEIF support varies by lab and by how recently their pipeline has been updated. Sending a .heic file to a lab whose workflow doesn’t expect it can produce a color-management problem — a wide-gamut HEIF’s embedded profile being misread or ignored, so a Display P3 image prints as though it were sRGB — but whether that actually happens depends on the specific lab’s software, and it isn’t a given. If you’re delivering to a lab or client you don’t control, ask first or convert to JPEG/TIFF to remove the variable.
Social platforms generally re-encode whatever you upload rather than preserving your original file, so the format you upload in matters less than the format you shoot in. Exactly how any given platform’s pipeline handles a HEIF upload — whether it decodes it, what it re-encodes to, what quality setting it applies — is specific to that platform, can change without notice, and isn’t something to assume without checking your own test upload first.
The 8-Bit vs. 10-Bit Question Is More Important Than the Format Name
One thing worth separating out: the biggest practical advantage of HEIF for still photographers isn’t compression efficiency, it’s higher color depth. Whether your specific camera can capture 10-bit stills varies by model and manufacturer — check your camera’s own specification sheet rather than assuming, since it isn’t universal even among recent mirrorless bodies. If it can, and you’re saving JPEG instead, the camera silently discards two bits per channel at the point of export. That’s a reduction from 1,024 to 256 tonal steps per channel, which is only visible in smooth gradients and subtle shadow/highlight work, but it’s a real, unrecoverable loss at the point of export.
If you’re shooting raw and processing in Lightroom or Capture One, this distinction doesn’t apply — you’re exporting to JPEG or TIFF at whatever depth you specify. HEIF only enters the equation if you’re shooting compressed files in-camera and relying on them as your final output, or if you’re using a camera that applies HDR tone mapping in-camera before writing the file.
A Practical Decision Framework
Rather than a single recommendation, here’s how to think through it based on your actual workflow:
Keep JPEG as default if:
- You deliver files directly to clients or print labs without editing
- Any part of your chain involves older software you haven’t confirmed has HEIF support
- You shoot for web use where upload transcoding is guaranteed anyway
- You share files across mixed operating environments without controlling the endpoints
HEIF makes sense if:
- You shoot in-camera JPEG (not raw) and want a smaller storage footprint without dropping visible quality
- Your camera supports 10-bit HEIF and you display or output to HDR-capable screens
- Your entire workflow stays within Apple’s ecosystem — macOS, iOS, Photos.app, or equivalent — where HEIF is genuinely a first-class format
- You’re building a personal archive and plan to convert to delivery formats at output time
Consider a hybrid approach if:
- Your camera supports simultaneous JPEG + HEIF output — a growing number of models do, though it varies by manufacturer, so check your camera’s spec sheet — which lets you keep the HEIF as archive and the JPEG for immediate use
Before You Change That Setting
If you’re genuinely considering the switch, the simplest first test is to shoot a sequence in both formats — most cameras with HEIF support let you do this simultaneously — and then verify that every application you use regularly can open the HEIF file correctly. Don’t assume; check the color rendering against the JPEG, check that embedded metadata is preserved, and check that your backup software indexes the file correctly.
Understanding how compression artifacts actually form and why re-saving a JPEG loses a little data on every pass are useful foundations before choosing a format for in-camera output. Our File Formats and Image Quality sections cover those mechanics in more depth if any of that is still fuzzy.
The format question isn’t really “is HEIF better?” — on paper, in most respects, it is. The question is whether your workflow is ready to handle it end-to-end without a silent failure somewhere in the chain. Test that first, then change the menu setting.