Skip to content
heic.fyi

Learn

HEIC vs AVIF vs WebP vs JPEG XL, measured

At equal quality, JPEG XL made the smallest files in our test of 25 images, HEIC and AVIF finished level with each other about 22% below JPEG, and WebP was no smaller than JPEG at high quality. Browser support runs the other way: WebP and AVIF reach about 97% of users, HEIC 17%, and JPEG XL reached Chrome stable on 6 October 2026. Below: sizes, speed, support, licences and which to use.

By the heic.fyi teamUpdated 14 min read

Key takeaways

  • JPEG XL was smallest at every quality we tested above 60. To match JPEG’s SSIMULACRA2 score, its files were a median 61% of the JPEG’s bytes at score 70, 66% at 80 and 63% at 90. It won outright on 21 of 24 photos at score 80.
  • HEIC and AVIF were level. Both needed about 69% of JPEG’s bytes at score 70, 78% at 80 and 86% at 90. HEIC was ahead at low quality (score 60: 57% against 61%).
  • Lossy WebP saved nothing at high quality. 92% of JPEG’s bytes at score 70, 102% at 80, and at 8-bit 4:2:0 it could not reach score 90 on 14 of 25 photos.
  • The winner depends on the metric. Judged by SSIM or PSNR, HEIC and AVIF were smallest and JPEG XL third. SSIMULACRA2, which we used, favours JPEG XL; no metric replaces looking, so the crops are below.
  • Support reverses the order. Can I use: WebP 97.08% of users, AVIF 96.33%, HEIC 16.93% (Safari 17 and later), JPEG XL in Chrome 155 (6 October 2026) and partly in Safari 17.
On this page
  1. Which is better: HEIC, AVIF, WebP or JPEG XL?
  2. How much smaller is each format at the same quality?
  3. Does the winner change with the metric?
  4. Which is faster to encode and decode?
  5. Which browsers and apps open each format?
  6. What about licences and patents?
  7. What features does each format have?
  8. HEIC vs PNG: what about lossless?
  9. Which format should I use?
  10. What we did not test
  11. How we measured

Which is better: HEIC, AVIF, WebP or JPEG XL?

It depends on what you are optimising. For the smallest file at a given quality, JPEG XL, then HEIC and AVIF level, then WebP and JPEG. For reach, WebP and AVIF, which almost every browser opens; HEIC opens natively only in Safari 17 and later, and JPEG XL only in Safari 17 (partly) and Chrome 155. For photos you keep on an iPhone or Mac, HEIC is already what the camera writes. Nothing here is a reason to convert a photo library you are happy with: re-encoding between lossy formats costs quality (see HEIC vs JPG).

0.61
JPEG XL, share of JPEG’s bytes at score 70

median of 25 photos

0.69
HEIC and AVIF at score 70

both; 0.78 at score 80

0.92
WebP at score 70

1.02 at score 80: no saving

96–97%
of users open WebP or AVIF

HEIC 16.93%. Source: Can I use data of 11 October 2026

Which image format to use, by situationSix situations and the format we would choose. Camera originals on Apple devices: HEIC. Sending or uploading: JPEG. Publishing on a website: AVIF or WebP with a JPEG fallback. A site that wants HDR or the smallest files: add JPEG XL beside a fallback. Screenshots, text and line art: PNG. A lossless archive smaller than PNG: JPEG XL or WebP.Camera originals on your own Apple devicesHEICSmaller than JPEG; Apple handles the restSending to people or uploading to formsJPEGOpens everywhere; HEIC is Safari-only in browsersPublishing photos on a websiteAVIF or WebPBoth near 97% of browsers; keep a JPEG fallbackA site that wants HDR or the smallest filesAdd JPEG XLChrome 155, Safari 17; serve it beside a fallbackScreenshots, text, line art, exact pixelsPNGLossless and universal; lossy codecs smear textLossless archive, smaller than PNGJPEG XL or WebPSmaller than PNG in our lossless test
Which format for which job. The reasons are our measurements below and the support and licence sources cited in this article. HEIC rows assume Apple’s sharing converts for you, as Apple describes; JPEG XL needs a fallback until more browsers ship it.

How much smaller is each format at the same quality?

For each of 25 photographs we encoded every format across a range of quality settings, scored each result, and read off how many bytes it takes to reach a given score. The images are the ones from our HEIC vs JPG test: 24 CC0 camera raws developed to 8-bit sRGB at 2400 pixels on the long edge (3.8 megapixels), plus one page of text and graphics we drew ourselves.

Bits per pixel needed to reach each quality score, by formatRate-distortion curves from our benchmark of 25 images. The vertical axis is the SSIMULACRA2 quality score from 40 to 94; the horizontal axis is median bits per pixel on a log scale from 0.1 to 4. A curve further left reaches the same quality with fewer bits. At a score of 80 the median image needs about 1.2916 bits per pixel as JPEG, 1.3114 as WebP, 1.0625 as HEIC, 0.9939 as AVIF and 0.8059 as JPEG XL.JPEGWebPHEICAVIFJPEG XL4050607080900.1250.250.51270 = high qualityMedian bits per pixel (log scale), fewer is better →SSIMULACRA2 score
Rate–distortion curves: median bits per pixel needed to reach each score (log scale; further left is better). At score 80 the median photo needed 1.29 bits per pixel as JPEG, 1.31 as WebP, 1.06 as HEIC, 0.99 as AVIF and 0.81 as JPEG XL. Markers are every 10 points; the dashed line is the 70 = “high quality” band from SSIMULACRA2’s documentation.
File size at the same SSIMULACRA2 score, as a fraction of the JPEG’s size (median of photos; middle half in brackets)
ScoreJPEG (typical file)WebPHEICAVIFJPEG XL
70 high382 kB0.92 (0.81–1.05)0.69 (0.54–0.79)0.69 (0.54–0.73)0.61 (0.56–0.69)
80622 kB1.02 (0.87–1.15)0.78 (0.65–0.90)0.78 (0.74–0.88)0.66 (0.58–0.70)
90 visually lossless1,747 kB1.02 (0.98–1.04), 11 photos0.87 (0.82–0.94), 210.86 (0.84–0.88), 210.63 (0.58–0.71), 21
Smaller than the JPEG in (score 70, 80, 90)16, 11, 4 photos24, 22, 2024, 21, 2125, 25, 21
Smallest of all five (score 70, 80, 90)0, 0, 08, 1, 05, 2, 012, 21, 11

0.78 means 78% of the JPEG’s bytes, 22% smaller. Each ratio is per photo, then the median: the size a format needs at that score divided by the JPEG’s. Photos are counted where both formats reached the score: 25 at 70, 24 to 25 at 80, and 21 at 90 (WebP reached it on 11, because lossy WebP is 8-bit 4:2:0 and tops out near 89.5). “Smallest of all five” counts the 25, 24 and 11 photos that every format reached. JPEG typical file is the median JPEG size at that score. At score 60, the HEIC median was 0.57, AVIF 0.61, JPEG XL 0.61 and WebP 0.86.

File size at equal quality as a fraction of JPEG, at three quality targetsMedian file size of WebP, HEIC, AVIF and JPEG XL as a fraction of the JPEG that scores the same on SSIMULACRA2, at three scores, with the middle half of photos shown as a bar. Below 1.0 is smaller than JPEG. At score 70: WebP 0.92, HEIC 0.69, AVIF 0.69, JPEG XL 0.61. At score 80: WebP 1.02, HEIC 0.78, AVIF 0.78, JPEG XL 0.66. At score 90: WebP 1.02, HEIC 0.87, AVIF 0.86, JPEG XL 0.63.← smaller than JPEGlarger →Score 70typical JPEG at this score: 382 kBWebP0.92HEIC0.69AVIF0.69JPEG XL0.61Score 80typical JPEG at this score: 622 kBWebP1.02HEIC0.78AVIF0.78JPEG XL0.66Score 90typical JPEG at this score: 1747 kBWebP1.02HEIC0.87AVIF0.86JPEG XL0.630.250.50.7511.25
The same data as a picture: each row is a format’s median at that score, the shaded bar is the middle half of photos, and the line at 1.0 is the JPEG. HEIC and AVIF sit together; JPEG XL sits left of both, widening with quality; WebP straddles 1.0.

Three patterns hold across the table. JPEG XL’s lead grows with quality: it needed 92% of HEIC’s bytes at score 70, 81% at 80 and 73% at 90 (medians of the per-photo ratios). HEIC and AVIF are close but not the same: AVIF was about 2% smaller than HEIC at scores 70 to 90 and about 2% larger at 60, so neither dominated. At low quality HEIC wins: at score 60 HEIC was smallest on 13 of 24 photos, JPEG XL on 6 and AVIF on 5. The spread across photos is wide: at score 80 HEIC needed between 0.65 and 0.90 of the JPEG’s bytes for the middle half of photos.

Apple’s WebKit team (opens in a new tab) says a HEIC photo can take about half the space of an equivalent-quality JPEG. We did not see half: 22% smaller at score 80 with x265. Apple’s encoder differs from ours, and the claim does not say how quality was matched. Google’s WebP FAQ (opens in a new tab) says lossy WebP is typically 30% smaller than JPEG; at these scores we found it about the same size, with libwebp at its slowest setting. Different images, JPEG encoders and quality yardsticks give different answers, which is why we show the spread.

Does the winner change with the metric?

Yes, and it is the main caveat on the table above. SSIMULACRA2 comes from the JPEG XL ecosystem, and libjxl tunes its encoder with related perceptual measures, so it may flatter JPEG XL. We re-ran the comparison with two classic metrics we had already recorded for every encode. For each photo we took the SSIM (or PSNR) of the JPEG saved at quality 85 and read off what each format needs to match it.

Median share of the quality-85 JPEG’s bytes needed to match its SSIM or PSNR (25 photos)
MetricHEICAVIFJPEG XLWebP
SSIM0.540.540.610.69
PSNR0.550.530.580.63
SSIMULACRA2 (for comparison)0.820.800.671.05

Under SSIM and PSNR, HEIC and AVIF come out about 45% below JPEG, which is where the old “HEIC is half the size” figure comes from; JPEG XL falls to third. The last row is the same anchor, the quality-85 JPEG, scored with SSIMULACRA2; it matches what we measured in the HEIC vs JPG article for HEIC, AVIF and WebP. Neither classic metric models how people see artefacts, and SSIMULACRA2 is designed to, but it is not a human rating either. The SSIMULACRA2 figures are from the Python port; see How we measured for how it compared with the reference tool.

What do the files look like at the same score?

Scores are a proxy, so here are real crops, each enlarged 2× so artefacts show. For each photo we encoded every format at the setting that scores about 80 and cut out the same region. The file size under each label is for the whole 2400-pixel image. The scores printed on each tile come from the reference SSIMULACRA2 tool; they differ by a point or two because quality settings come in whole steps.

Six crops of a white wooden post cap against blue-grey siding: the original, then JPEG, WebP, HEIC, AVIF and JPEG XL. They look alike.
Architecture, where the formats look the same. Fujifilm X-T20 photograph (raw.pixls.us (opens in a new tab) sample 1178, CC0). JPEG 296 kB, WebP 191 kB, HEIC 135 kB, AVIF 132 kB, JPEG XL 157 kB. We cannot tell the five apart at this size. On this photo JPEG XL was not the smallest.
Six crops of frosted plant stems against a brown background: original, JPEG, WebP, HEIC, AVIF and JPEG XL. They look alike.
Fine texture. Frosted foliage, a CC0 photograph from raw.pixls.us (sample 1068, Sony ILCA-68). JPEG 305 kB, WebP 227 kB, HEIC 153 kB, AVIF 155 kB, JPEG XL 142 kB. The three modern codecs are about half the JPEG’s size and, to our eye, as good.
Six crops of blue text on a yellow bar: original, JPEG, WebP, HEIC, AVIF and JPEG XL. The JPEG XL crop shows a yellow smear under the text, and the HEIC crop shows faint colour fringes at the letter edges.
Text on flat colour (a page we drew). JPEG 302 kB, WebP 183 kB, HEIC 81 kB, AVIF 31 kB, JPEG XL 65 kB, at scores of 77 to 78. AVIF is the smallest and looks the cleanest; JPEG XL, which won on photos, shows a smeared yellow band under the letters at this setting; HEIC shows faint colour fringes. Synthetic images are where the metric and the eye can disagree most, and lossy photo codecs are not what to use for text: see the lossless table below.

Which is faster to encode and decode?

Faster encoding and decoding go to the older, simpler codecs, and HEIC is the slowest of the five at both. We timed each format on every photo at the setting that scores 80, one at a time, taking the best of three runs. These are software encoders and decoders on a cloud CPU: phones encode HEIC in dedicated hardware, and browsers decode AVIF and WebP in optimised native code, so treat the ratios as the finding.

Median time per photo at 2400 px (3.8 megapixels), at the setting that scores 80 (25 photos, 24 for WebP)
FormatEncode, wall-clockEncode, CPU timeDecodeSoftware
JPEG0.03 s0.03 s22 mslibjpeg-turbo (Pillow)
AVIF0.85 s2.9 s42 mslibaom speed 6 and libavif (pillow-avif-plugin)
WebP1.21 s1.2 s79 mslibwebp method 6
JPEG XL1.89 s1.8 s115 mslibjxl 0.12.0 effort 7, one thread (imagecodecs)
HEIC2.41 s8.2 s219 msx265 4.2 (multi-threaded) and libde265 (pillow-heif)

Wall-clock is what you wait; CPU time is the work done across all threads: x265 and libaom used several cores, libwebp and libjxl one. At this setting the files were about 624 kB (JPEG), 579 kB (HEIC), 522 kB (AVIF), 432 kB (JPEG XL) and 672 kB (WebP) in the median, but the sizes in the first table are per-photo ratios, which are the fair comparison. Slower, smaller settings exist for every encoder: libaom speed 6 and libjxl effort 7 are middle settings, not the best.

Two conclusions. JPEG XL pays for its size with encode time at effort 7: about two seconds a photo, twice AVIF’s wall-clock, but on one thread, so it parallelises across files well. HEIC is the expensive one: 8.2 CPU-seconds per 3.8-megapixel photo and a decode five times slower than AVIF’s. That is why phones use hardware, and why a batch of thousands is slower in HEIC than in any other format here. The numbers differ from the HEIC vs JPG timings (3.6 s encode there, at a different setting and with the machine busy), so compare within a table, not across articles.

Which browsers and apps open each format?

WebP and AVIF are safe for the web today; HEIC is not; JPEG XL is new. These are Can I use’s figures for 12 October 2026 (usage from StatCounter, September 2026). The JPEG XL share does not yet include Chrome 155, which reached stable on 6 October.

First browser version that displays each format by default, and global usage
BrowserHEICAVIFWebPJPEG XL
Chromeno8532155; behind a flag from 145
Edgeno12118no (flag only in old versions)
Firefoxno9365158, not yet released (157.0.1 is current)
Safari, macOS1716.416 (14 partial)17, partial
Safari, iOS17161417, partial
Global usage16.93%96.33%97.08%0.02% + 16.93% partial

“Partial” for Safari means still images work but animated JPEG XL and progressive decoding do not, per Can I use. Chrome 155’s stable date is from the Chromium schedule; Firefox’s from Mozilla’s release list. Edge’s row is Can I use’s; we did not test Edge.

Chrome’s decision matters most. Google’s Chrome blog (opens in a new tab) (6 October 2026) says Chrome 155 ships JPEG XL decoding, using the Rust decoder jxl-rs, and recommends trying both AVIF and JPEG XL. Chrome had previously removed its earlier JPEG XL support in 2022, according to Wikipedia’s summary. Safari has decoded JPEG XL since 17.0; WebKit’s notes mention progressive loading and lossless recompression of JPEG files.

Operating systems and apps differ from browsers. Android’s supported-formats page lists HEIF decoding from Android 9 (device optional; 10-bit needs the optional HEVC Main10 profile) and encoding from 10, AVIF decoding from Android 12 and encoding from 14, WebP from 4.0, and no JPEG XL row. Windows needs the HEIF Image Extension for HEIC (see open HEIC on Windows); the Microsoft Store also lists a JPEG XL Image Extension. For code, see HEIC for developers. For browsers, HEIC browser support covers the HEIC detail.

What about licences and patents?

Who licenses what, from each project’s own terms
FormatCodecSoftware licencePatent position
HEICHEVC (H.265)libheif and libde265 LGPL; x265 GPL v2 or commercial; kvazaar (BSD) is an alternative encoderLicences are sold through pools such as Access Advance and Via LA (links below). Software licences do not grant patent rights.
AVIFAV1Open-source encoders such as libaom, SVT-AV1 and rav1eThe Alliance for Open Media patent licence grants a “perpetual, worldwide, non-exclusive, no-charge, royalty-free” licence under each licensor’s necessary claims. Separately, Sisvel runs an AV1 pool (21 patent owners, over 1,900 patents, July 2025) for finished products.
WebPWebP lossy and losslesslibwebp, BSD 3-clause (Google)Google’s patent grant: perpetual, irrevocable, royalty-free, ending for anyone who sues over the codec.
JPEG XLISO/IEC 18181libjxl, BSD 3-clauseGoogle’s patent grant for the implementation, royalty-free, ending on litigation; the JPEG Committee describes the reference software as royalty-free.

None of this is legal advice. “Royalty-free” in a licence is a statement by those licensors; it cannot bind patent owners outside them, which is why a pool like Sisvel’s can exist beside the AOM licence. We did not research JPEG’s or PNG’s patent position. Check the terms that apply to your product, especially if you ship an encoder or decoder.

The pools’ own pages are Access Advance (opens in a new tab) and Via LA (opens in a new tab). The practical difference: a website that serves WebP or AVIF files to browsers is not shipping a codec. An app that ships an HEVC encoder or decoder is closer to what the pools address: Access Advance describes its licence as covering devices, software and commercial content distribution on physical media. The open-source HEIC stack reflects the split: LGPL decoders, a GPL encoder. See HEIC for developers for the library-by-library licence table.

What features does each format have?

Features of JPEG, WebP, HEIC, AVIF and JPEG XLA grid of six features by five formats. Lossy compression: all five. Lossless: all except JPEG. Transparency: all except JPEG. Animation: WebP and AVIF in full, HEIC and JPEG XL in the format but little supported, not JPEG. More than 8 bits per channel: HEIC, AVIF and JPEG XL. HDR signalling: HEIC, AVIF and JPEG XL, partly JPEG through gain maps. Lossless recompression of existing JPEG files: JPEG XL only.JPEGWebPHEICAVIFJPEG XLLossy compressionLossless (we tested)TransparencyAnimationMore than 8 bitsHDR signallingLossless JPEG repackyeswith a caveatno
Features by format. Sources: Google’s WebP FAQ (lossy WebP is 8-bit 4:2:0, animation, alpha), the AVIF specification (8, 10 and 12-bit, alpha, image sequences, HDR signalling), jpeg.org (JPEG XL), libheif’s README and Android’s format table (HEIC), Android’s Ultra HDR page (JPEG gain maps), and our own lossless round trips. “Caveat” for HEIC animation means the format has image sequences that almost nothing displays; for JPEG XL animation, that Safari does not; for JPEG HDR, a gain map rather than a 10-bit file.
  • HEIC: HEVC in a HEIF container. libheif’s README lists alpha, depth maps, thumbnails, auxiliary images, several images per file, sequences and tiles, and 8 to 12-bit depth with the right decoder. Apple’s HDR photos use a gain map stored as an auxiliary image (see HEIC HDR).
  • AVIF: AV1 in the same container family. The specification supports 8, 10 and 12 bits, alpha as an auxiliary image, avis image sequences, HDR signalling (mastering-display and content-light-level properties) and depth maps. AVIF’s Baseline profile (AV1 Main profile, level 5.1 or lower) limits picture size, so very large photos are stored as a grid of tiles.
  • WebP: lossy WebP is limited to 8-bit YCbCr 4:2:0, lossless is RGBA, the maximum is 16,383 × 16,383 pixels, and animation is supported. That is why it could not reach score 90 on most of our photos.
  • JPEG XL: jpeg.org lists lossless JPEG recompression, HDR and high bit depth, alpha, animation, and lossless and progressive coding. Recompression is the feature none of the others has: an existing JPEG becomes a smaller JPEG XL file that converts back to the identical JPEG.
  • JPEG: 8 bits per channel, no alpha. HDR happens through a gain map, as in Android’s Ultra HDR.

HEIC vs PNG: what about lossless?

PNG has no quality setting, because it is lossless, so “PNG vs HEIC quality” is really two questions. Lossy HEIC against PNG: a HEIC at score 80 is a small fraction of a PNG but not the same pixels. For a 2400-pixel photo, our PNG median was 6.6 MB against a 553 kB HEIC. Lossless HEIC against PNG: HEIC can be lossless too (x265 with 4:4:4 chroma and the identity matrix; we decoded every file and compared each pixel), but it was 7% larger than PNG.

Lossless size as a fraction of an optimised PNG (25 images, every result decoded and compared pixel for pixel)
FormatMedian vs PNGSmaller than PNG inMedian encode time
PNG (Pillow, optimised)1.00n/a1.7 s
JPEG XL lossless, effort 70.8825 of 257.0 s
WebP lossless, method 60.9025 of 2527.5 s
AVIF lossless, libavif, speed 61.0012 of 256.0 s
HEIC lossless, x265 4:4:41.072 of 254.7 s

All 25 round trips were bit-exact. Encode times were taken three jobs at a time on a shared machine, so read them as rough. The text-and-graphics page is the outlier: WebP lossless was 31% of its PNG, JPEG XL 98%, AVIF 157% and HEIC 453%. We did not test 16-bit images.

Use PNG for screenshots, text and line art you must open anywhere. If you want smaller lossless files, lossless WebP and JPEG XL beat PNG in our test, and lossless HEIC does not. PNG’s third edition (W3C Recommendation, 24 June 2025) also covers 16-bit samples, animation and HDR signalling, so it is not the limited format it once was.

Which format should I use?

A plain decision table
SituationUseWhy
Photos you take on an iPhone or MacHEIC (keep it)It is what the camera writes, and Apple says HEIF uses less space than JPEG at the same visual quality; we measured 22% at score 80 with x265
Sending to people whose devices you do not knowJPEGHEIC is Safari-only in browsers and Apple often converts it for you anyway; HEIC to JPG does it in your browser
A website with photosAVIF or WebP, JPEG fallback96 to 97% of users; at equal quality AVIF was 22% smaller than JPEG, WebP no smaller. HEIC to AVIF, HEIC to WebP
A website that can serve three formatsJPEG XL, then AVIF, then JPEGJPEG XL was smallest in our test and Chrome 155 and Safari 17 decode it; use <picture> so others fall back
Screenshots, text, line artPNGLossless and universal; HEIC to PNG keeps transparency
A lossless archive you want smaller than PNGJPEG XL or WebP lossless12% and 10% smaller than PNG in our test; check your software opens them
Shrinking an existing JPEG library with no lossJPEG XL recompressionReversible to the identical JPEG; only if everything you use can open JPEG XL

What we did not test

  • Other encoders and speeds. One encoder per format, at one speed: x265 (libheif default preset), libaom speed 6, libwebp method 6, libjxl effort 7, libjpeg-turbo. Slower settings, SVT-AV1, rav1e, kvazaar, mozjpeg and jpegli could change the ranking; Apple’s HEIC encoder is untested.
  • Other images. 24 clean 8-bit sRGB raw developments at 3.8 megapixels and one synthetic page, not noisy phone JPEGs, HDR photos or 48-megapixel files.
  • People. One metric family and no human ratings. We show crops so you can look.
  • HDR, 10-bit, alpha and animation. The feature table is from documentation, not from our encodes, apart from lossless.
  • Decoding on phones, power use and progressive loading. Our timings are software decoders on one cloud machine.
  • Browsers. We read Can I use and vendor pages; we did not run the formats in Edge, Firefox or Safari ourselves.

How we measured

Images. The 25 images from the HEIC vs JPG benchmark, listed there: 24 camera raws released CC0 on raw.pixls.us (opens in a new tab) (cameras from an iPhone 7 Plus to mirrorless and DSLR), developed with libraw at full resolution (camera white balance, sRGB, 8-bit), resized to 2400 px on the long edge with Lanczos, and one text-and-graphics page we drew. The originals are PNGs and every codec was scored against them.

Encoders and settings. JPEG: libjpeg-turbo 3.1.4 via Pillow 12.3.0, optimised Huffman tables, 4:2:0, quality 20 to 100. HEIC: pillow-heif 1.8.0, libheif 1.23.4, x265 4.2, 8-bit 4:2:0, libheif’s default preset, quality 10 to 90. WebP: libwebp 1.6.0, method 6, quality 20 to 100. AVIF: pillow-avif-plugin 1.6.0 with libaom 3.14.1, speed 6, 4:2:0, quality 10 to 100. JPEG XL: libjxl 0.12.0 through imagecodecs 2026.10.10, effort 7, distances 0.25 to 12. Lossless AVIF used libavif 1.4.2 through imagecodecs at quality 100. All encoders ran single-threaded or at their defaults.

Scoring. Every result was decoded and compared with its original using SSIMULACRA2 from the PyPI ssimulacra2 0.3.0 Python port, plus SSIM and PSNR from scikit-image 0.26.0. Size at equal score is interpolated per photo, linearly in log-bytes between the two measured points that bracket the target; a photo where a format never reached the target is left out and counted. Port versus reference. We built the reference SSIMULACRA2 tool from libjxl 0.12.0 and compared it with the port on 42 encodes of three images. On the two photos (28 encodes) the port was a median 0.25 points from the reference (largest gap 1.9), and slightly generous: +0.2 points on average, +0.6 for JPEG XL, +0.4 for HEIC and about 0 for the rest, so it flatters JPEG XL a little. On our synthetic text page it read 2 to 7 points above the reference, so treat that one image’s scores as unreliable; it is 1 of 25. The scores printed on the crops above are from the reference tool. The comparison is in format-comparison.validate.json.

Timing. Per photo, each format encoded and decoded three times at the setting that scores 80, one process at a time, best run kept, on a shared four-vCPU cloud container (Intel Xeon 2.8 GHz). Other jobs shared the CPU, so use the ratios, not the seconds. Reproduce. python scripts/benchmarks/format-comparison.py all after python scripts/benchmarks/heic-vs-jpg.py fetch develop; it writes format-comparison.results.json and format-comparison.points.csv (about 1,400 measured points, plus the earlier benchmark’s points for the four formats it also covers).

Frequently asked questions

Try it yourself

Related reading

Sources

How we research and correct: editorial policy.

Written by the heic.fyi team · Last updated: · Spotted an error? Tell us.