Chrome Ships JPEG XL: Should You Replace AVIF?
Chrome 155 now decodes JPEG XL, which paints a large photo before the download finishes. Is that a reason to swap your AVIF images, or only some of them?
- Google announced JPEG XL decoding in Chrome 155 on October 6.
- JXL is useful for lossless images and progressive rendering; AVIF remains a candidate for web-quality compression.
- Compare representative images and deliver a fallback through
picture.
Chrome 155 can display .jxl images
The Chrome announcement introduces decoding support. It does not convert a site's existing files or add the feature to older browser versions.
MDN's format guide lists lossy and lossless compression, HDR, transparency, and animation among JPEG XL's capabilities. It can also transcode existing JPEGs losslessly while allowing the original JPEG file to be reconstructed. That preserves the JPEG's information; it does not recover detail discarded when the JPEG was first compressed.
Smaller files depend on the use case
Mozilla's comparison favors JXL for lossless compression, progressive rendering, and recompressing JPEGs without further loss. AVIF has strengths at web-quality photographic compression and on images mixing sharp edges with flat areas.
| Priority | What to evaluate |
|---|---|
| Lossless imagery or JPEG recompression | Include JPEG XL. |
| Small photos at web-quality settings | Compare AVIF and JXL outputs. |
| Showing a large image during download | Evaluate progressive JXL rendering. |
Progressive rendering lets an image become visible before the download completes. File size and how soon the subject appears are different measures. Mozilla recommends testing images representative of the site at an appropriate quality level.
The decoder matters as well as compression
Chrome integrated jxl-rs, a Rust decoder. Image decoders process untrusted binary data, making memory access errors a security concern. Google's announcement describes both its memory-safety approach and SIMD performance work.
That implementation decision explains part of the browser change. A publisher still needs to choose formats against its own image-quality and file-size requirements.
Keep a fallback alongside the JXL file
The picture element lets a browser select a supported source. This minimal example assumes both images already exist:
<picture>
<source srcset="photo.jxl" type="image/jxl" />
<img src="photo.jpg" width="1200" height="800"
alt="Coastal landscape at sunset" />
</picture>The MIME type is image/jxl. A browser unable to use that source can select the JPEG from img. The markup does not generate either file: conversion and delivery assets must already be in place.
A practical rollout starts with representative images, selects a suitable format and quality, then adds a fallback for unsupported clients. Browser support alone does not justify converting an entire library.
Frequently asked questions
Does transcoding restore the original photo's quality?
No. Lossless JPEG transcoding preserves the existing JPEG's information. It cannot restore detail already discarded.
Can I remove the JPEG fallback now?
Keep an alternative if your audience includes unsupported environments. The picture element provides format selection.
JPEG XL adds another delivery option. Compare it with AVIF, then deploy it where its strengths match the image.