Browser support ends one argument
Jake Archibald started his October 2026 comparison after JPEG XL reached the major browsers. MDN now lists JPEG XL support in Chrome, Edge, Firefox, and Safari. MDN still recommends a fallback because support is not universal.[1][2]
The HTML standard already has the delivery control. A <picture> element can offer several <source> candidates before one required <img>. A browser can skip a source when its declared MIME type is unsupported.[3]
Format support tells you what the browser can decode. It does not tell you which file wins for your image.
Today's encoders make the decision
Archibald compared AVIF with two JPEG XL encoders across photos, screenshots, illustrations, transparency, high dynamic range, JPEG recompression, and lossless work. He targeted matched perceptual scores rather than equal quality-slider numbers. His test set used avifenc 1.4.2, libjxl 0.12.0, jixel 0.4.2 at revision f487299, and cwebp 1.6.0.[1]
For lossy photos, AVIF files were usually smaller. The best JPEG XL result was typically 15 to 25 percent larger at default effort and 6 to 20 percent larger at maximum effort. For screenshots and illustrations, the JPEG XL files were 30 to 90 percent larger at default effort. AVIF also won the transparency comparisons.
JPEG XL kept two useful jobs. It made existing JPEG files 9 to 20 percent smaller without adding another lossy generation. It also won the lossless comparisons. Those are specific routes, not reasons to replace every web image.
Encode time belongs in the build budget
The comparison recorded file size, encoding time, encoding memory, and browser decode time. AVIF generally produced the better total for web delivery. JPEG XL through jixel could encode faster at default settings, but the resulting file was larger. Matching AVIF's size required much slower jixel settings.
Archibald also found that high libjxl effort barely helped and sometimes made files larger. This is why a file-extension policy is weak. The encoder and effort level are part of the result.
The current libjxl 0.12.0 and libavif 1.4.2 release pages match the versions named in the benchmark.[4][5]
Ship a fallback, then keep measuring
A useful default for web raster images is AVIF with full color resolution, a measured quality target, and a fallback. Try JPEG XL when AVIF produces an outlier, when you need lossless output, or when you want to repackage an existing JPEG without another lossy pass.
Keep logos, icons, and diagrams in SVG when they are vectors. Use video for animated sequences when its controls, loading behavior, and accessibility fit the page. Do not turn a codec choice into a site-wide identity.
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.jxl" type="image/jxl">
<img src="hero.jpg" width="1600" height="900"
alt="Describe the image, not the codec">
</picture>The order above is a policy choice. Reverse the modern sources if your matched tests favor JPEG XL. Keep explicit width and height so the fallback reserves the same layout space.