JPEG XL vs HEIC
Both promise photos at about half the size of JPEG. We encoded 16 photos with each to the same visual quality: at the quality libheif uses by default they tie, at higher quality JPEG XL wins, at lower quality HEIC does. The differences that decide it are support, bit depth and patents.
by Robert Castillo · Published
The short answer
On file size it is closer than either side likes to admit. At an SSIMULACRA2 score of 80, which is where libheif's default quality (50) lands, they came out level: the median difference across 16 photos was 0.1%, and each format won on half of them. Push the quality higher and JPEG XL pulls ahead, up to 23% smaller at visually lossless. Drop it lower and HEIC is the smaller one: JPEG XL came out 4% to 9% larger in the median, and much larger on a few photos.
The real differences are elsewhere. HEIC is what an iPhone already produces and what Apple's devices open without thinking, but it depends on HEVC, a patent-licensed video codec, and outside Safari no major browser shows it. JPEG XL is royalty-free, opens by default in Chrome, Firefox and Safari since October 2026, kept a full 16 bits where x265, the HEIC encoder we used, stopped at 12, and needed between a half and a seventh of HEIC's processor time to encode, depending on the quality.
Same visual quality: which file is smaller?
We reduced 16 photos (seven from phones, nine from cameras) to 2048 pixels on the long side and encoded each one at many quality settings as HEIC, with libheif and the x265 encoder, and as JPEG XL. Every file was decoded and scored against the original with SSIMULACRA2, and for each photo we worked out how big each format has to be to reach the same score. We ran HEIC twice: with libheif's default 4:2:0 colour subsampling, which halves the colour resolution, and with full 4:4:4 colour.
| Score | HEIC 4:2:0 | HEIC 4:4:4 | JPEG XL (vs HEIC 4:2:0) |
|---|---|---|---|
| 60 · artefacts visible | 149 KB | 157 KB | 168 KB (+9%, 6/16) |
| 70 · high quality | 219 KB | 228 KB | 239 KB (+4%, 7/16) |
| 80 · identical side by side | 372 KB | 378 KB | 382 KB (level, 8/16) |
| 85 · identical when flipping | 561 KB | 554 KB | 535 KB (−7%, 13/16) |
| 90 · visually lossless | 1,216 KB* | 1,123 KB | 964 KB (−23%, 14/14) |
Sizes are the median across the 16 photos, scaled to a 2048 × 1536 picture (3.1 megapixels). HEIC 4:2:0 is libheif's default. In brackets under JPEG XL: its median difference against default HEIC, worked out photo by photo (so it does not always match the gap between the medians), and on how many photos JPEG XL was the smaller file. *Only 14 of the 16 photos reached 90 as default HEIC.
Two things stand out. First, the crossover sits right around 80, and that is exactly where libheif's default quality of 50 lands: our photos scored a median just under 80 with it. Second, HEIC with its default settings hits a ceiling: on 2 of the 16 photos it never reached 90, even at quality 95, the highest we tried, because of the halved colour resolution. Full 4:4:4 colour got every photo there and narrowed the gap at 90 to 13%, but JPEG XL was still smaller on all 16.
Which photos favour which format
The median hides a lot of spread, and the spread follows the content of the picture.
HEIC wins clearly on smooth and dark images at lower quality. The two swans against a plain blue sky needed 73% more bytes as JPEG XL than as HEIC at a score of 70, and the two night scenes needed 26% to 29% more. HEVC was built to squeeze video into low bitrates, where keeping flat areas clean is most of the job, and at modest quality that shows.
JPEG XL wins on fine detail and as quality rises. The rural landscape and the aquarium came out smaller as JPEG XL at every level we tested. And by a score of 85 the picture flips for almost everything: JPEG XL was smaller on 13 of 16 photos, including the swans, which ended up 43% smaller than HEIC. Only the shop front at night stayed clearly in HEIC's favour (11%); the train station (3%) and the locomotive (level) were close calls.
So if you mostly keep compact, "good enough" copies of skies and night shots, HEIC was the more efficient of the two in our sample (one sky and two night shots). If you keep high-quality masters, JPEG XL is.
Lossless: where HEIC falls behind
HEIC can be lossless too, though almost nobody uses it that way. We tried it with the recipe heif-enc itself recommends (full 4:4:4 colour, RGB instead of YCbCr) on 8 of the photos and our 5 screenshots, and checked every result pixel by pixel. It really was lossless: zero pixels changed. It just wasn't small.
| Images | Best PNG | HEIC lossless | JPEG XL lossless |
|---|---|---|---|
| 8 photos | 32.14 MB | 36.59 MB | 21.55 MB |
| 5 screenshots | 0.74 MB | 2.27 MB | 0.92 MB |
Lossless HEIC came out 14% bigger than a well-optimised PNG on photos and three times bigger on screenshots. JPEG XL at its default effort was 41% smaller than lossless HEIC on the photos and 60% smaller on the screenshots, and on the photos it used about a third of the processor time. If you need an exact copy of an image, HEIC is the wrong tool.
Converting the HEIC photos you already have
With JPEG there is a trick: JPEG XL can re-pack an existing JPEG without touching a pixel and give the original back later. There is no equivalent for HEIC. Converting a HEIC means decoding it to pixels and encoding again, and we measured what that costs on 8 photos saved as HEIC at quality 60, which on our photos gave a high median score of 86.
Lossless JPEG XL keeps the HEIC's quality exactly, but the file is about three times bigger (2.9 times in total), because it faithfully stores every compression artefact the HEIC already had. Lossy JPEG XL at its default setting came out 9.5% smaller than the HEIC in total (9.0% in the median), but the score dropped from 86 to 82 in the median: a second round of compression always costs something.
So converting your iPhone library to JPEG XL to save space doesn't work. Convert copies when you need a photo to open somewhere HEIC doesn't, such as Chrome, Firefox or a Windows PC without the HEVC extension, and keep the originals. Our HEIC to JPEG XL converter does that in the browser without uploading anything.
Encoding effort
HEIC borrows a video encoder, and video encoders are slow when you ask for quality. At a score of 80, x265 used a median of 3.0 seconds of processor time per megapixel with 4:2:0 colour and 3.6 with 4:4:4, against 0.77 for cjxl at its default effort. At 90 it was 5.0 seconds against 0.67. That is roughly four to seven times more work for HEIC; at the lowest level we tested, 60, the gap shrank to about two times.
Two caveats. x265 spreads that work across several threads, so the wait is shorter than the processor time suggests, and libheif runs it with the slow preset by default; faster presets exist and trade compression for speed. And phones don't use x265: an iPhone uses Apple's own encoder, so these numbers say nothing about how fast your phone saves a photo. They matter when you convert or export on a computer.
Bit depth and HDR: what we could actually store
Both formats are sold as HDR-ready, and both are. The difference shows up at the edges. We took one of our photos as a 16-bit PNG and tried to keep all 16 bits.
Our HEIC encoder topped out at 12 bits. The limit is x265's, not necessarily HEVC's: with libheif 1.17.6 and the x265 3.5 encoder, heif-enc happily wrote 8-, 10- and 12-bit files, and refused 16-bit outright with "Bit depth not supported by x265". Its default for a 16-bit input is 10 bits, so if you don't ask, you get 10. Even the "lossless" mode stores 10 or 12 bits of a 16-bit source, which is not lossless.
JPEG XL kept all 16 bits in lossless mode, and in lossy mode the file is still a 16-bit file, as jxlinfo reports, instead of being cut down to 10 or 12 bits. The format goes further still, up to 32-bit floating point, which matters to people editing HDR or scientific images rather than to anyone taking holiday photos.
There is also a practical catch on the HEIC side: Google's own documentation says that on Android, 10-bit HEIF decoding "requires optional HEVC Main10 profile", so a phone may open the 8-bit version of a picture and not the 10-bit one. For phone HDR photos, both formats can carry the gain maps that newer phones use; libjxl added its gain map API in version 0.11 (September 2024).
Support in October 2026
Here HEIC and JPEG XL have almost opposite strengths: HEIC is built into phones and operating systems, JPEG XL is now in the browsers.
| Where | HEIC | JPEG XL |
|---|---|---|
| iPhone, iPad, Mac | Native since iOS 11 and macOS High Sierra (2017); the default camera format | From iOS 17 and macOS 14 Sonoma, according to Apple; Safari 17 shows it |
| Android | Decoding since Android 9, saving since Android 10; 10-bit is optional per device | Not in Android's official format list |
| Windows 11 | Free HEIF extension plus the HEVC Video Extensions, $0.99 in the Microsoft Store | Free JPEG XL Image Extension from Microsoft, version 24H2 or later |
| Chrome | No | Yes, by default since Chrome 155 (6 October 2026) |
| Firefox | No | Yes, since Firefox 158 (13 October 2026) |
| Edge | No | No: Edge 155 uses Chrome's engine but doesn't display it |
| Safari | Yes, since Safari 17 | Yes, since Safari 17 (no progressive loading or animation) |
So the honest summary is: if the photo stays inside Apple's world, HEIC is the path of least resistance, because the camera already made it. The moment it has to appear in a web page, JPEG XL now works in Chrome, Firefox and Safari, and HEIC only in Safari. Edge 155 uses Chrome's engine but doesn't display JPEG XL (Microsoft withdrew it from its release notes on 9 October 2026), so test your own browser before relying on it.
Patents and licences
This is the least visible difference and, long term, maybe the most important one.
HEIC is a container (HEIF) holding an image compressed with HEVC, the H.265 video codec, and HEVC is covered by patents licensed for a fee. Licensing is split across patent pools and individual holders: Access Advance describes its HEVC Advance pool as covering "many thousands of essential, high-quality patents", and the HEVC/VVC pool that Via LA ran until Access Advance took it over in December 2025 publishes a rate of $0.30 per device in region 1 and $0.20 in region 2 after the first 100,000 units, with an annual cap of $30 million. Whatever the exact reasons behind each company's decision, the visible result is that Windows charges $0.99 for its HEVC extension while the JPEG XL one is free, and that Chrome and Firefox now display JPEG XL but still not HEIC.
JPEG XL was standardised by the JPEG committee as ISO/IEC 18181 with a royalty-free reference implementation. The reference library, libjxl, is BSD-licensed and comes with a patent grant in which Google gives every user a "perpetual, worldwide, non-exclusive, no-charge, royalty-free" licence to the patents it holds on that implementation. As with any format, nobody can promise that no third party will ever claim a patent; what we can say is that we know of no patent pool or fee for JPEG XL, while HEVC is licensed through at least two pool programs.
Which one should you use?
Photos on your iPhone
Leave them as HEIC. The camera made them that way, Apple opens them everywhere, and re-encoding gains little.
Photos for a web page
JPEG XL, with a JPEG fallback in a <picture> element. HEIC only displays in Safari.
High-quality masters
JPEG XL. At visually lossless quality it was smaller on every photo, and it can keep 16 bits.
Compact copies of skies and night shots
In our sample (one sky and two night shots) HEIC was more efficient there at modest quality, if the places you open them support it.
Sharing with Windows users
Neither is ideal. Windows needs an extension for each; JPEG XL's is free, HEIC's video part costs $0.99.
Sending to anyone
Neither: send a JPEG. It is still the only format every device and every app opens.
How we measured
Photos: 16 JPEGs exactly as they were uploaded to Wikimedia Commons, all public domain (CC0): seven from phones (iPhone 13, iPhone 12, Pixel 7, Galaxy S21 Ultra) and nine from Fujifilm, Canon, Olympus, Nikon and Sony cameras. Each was reduced to 2048 pixels on its long side with ImageMagick (convert photo.jpg -auto-orient -resize 2048x2048 -strip), which erases most of the traces of its original JPEG compression, and that PNG is the reference everything is compared with.
Tools: libheif 1.17.6 with the x265 3.5 encoder (Ubuntu 24.04 packages; libheif's x265 defaults are preset slow, tune ssim, 4:2:0 colour) and libjxl 0.12.0. Commands: heif-enc -q Q ref.png -o out.heic at qualities 5 to 95, the same with -p chroma=444, and cjxl ref.png out.jxl -d D --num_threads=0 at distances 0.2 to 15. HEIC files were decoded with heif-convert, JPEG XL with djxl, and every result was scored against the reference with ssimulacra2 from libjxl 0.12.0. For each photo we interpolated the size each format needs to reach the same score.
Lossless and conversion tests: heif-enc -L -p chroma=444 --matrix_coefficients=0, the recipe printed by heif-enc's own help, against cjxl -d 0, with a pixel-by-pixel check of the decoded result (ImageMagick compare -metric AE). For the conversion test, HEIC files made at -q 60 were decoded with heif-convert and re-encoded with cjxl -d 0 and cjxl -d 1. These two tests used 8 of the 16 photos (four from phones, four from cameras): halfway through, we had to slow everything down and run one command at a time, memory-capped, because the server also hosts websites.
Timing: processor time (user plus system) per command on a shared server with 6 virtual AMD EPYC cores. x265 uses several threads and cjxl ran single-threaded; processor time adds up the work of all threads, so the comparison is about effort, not about how long you wait.
Limits: 16 photos is a small sample, not a study. SSIMULACRA2 comes from the team that created JPEG XL, and x265 is only one HEVC encoder; Apple's own encoder on an iPhone is a different program with different tuning, and we could not test it on a server. Our references come from JPEGs, not raw files, and are 8-bit. All scripts, results per setting as CSV, and the source and licence of every photo are kept with the measurements; the links to the 16 photos are in the method of our JPEG XL vs JPEG test.