JPEG XL vs AVIF stopped being a theoretical debate on October 6, 2026, when Chrome 155 reached stable with JPEG XL decoding switched on by default. For a commerce team, the question is now practical: which format should carry the product photography that sells the product, and what does it take to serve it on Magento Hyvä or Shopify Plus without breaking anything for the shoppers whose browsers still say no.
What changed in Chrome 155
Chrome 155 ships a JPEG XL decoder by default, built on jxl-rs, a pure Rust implementation written by the Chrome team. The Chrome announcement claims 30 to 50 percent better compression than JPEG, plus lossless mode, HDR and lossless transcoding of existing JPEG files. Google's own advice is to try AVIF and JPEG XL side by side, and it points JPEG XL at high fidelity and lossless photographic work.
The Rust part matters more than it looks. Image decoders parse untrusted bytes inside the renderer, which is exactly where memory bugs turn into exploits. Chrome says fuzzing and code review found no memory safety bugs across the decoder's history. Teams that read our note on the AVIF remote code execution fix in Next.js will recognise the pattern: every new format is new attack surface, and a memory safe decoder is a large part of why this one finally shipped after years of hesitation.
Support is now broad but uneven. According to caniuse, Safari has decoded still JPEG XL images since version 17, without progressive decoding or animation. Firefox 158, due out this week, enables it as well. Chromium browsers that lag behind Chrome's release train, and older Android installs, will not see it for a while.
JPEG XL vs AVIF for product photography
JPEG XL is the better fit for high fidelity product photography, and AVIF stays the better fit for small, heavily compressed images. That split follows from how each codec was designed, and it maps cleanly onto a typical catalogue.
AVIF comes from a video codec. It shines at aggressive compression, where a 600 pixel listing thumbnail can drop to a fraction of its JPEG weight with smoothing that most shoppers never notice. At high quality settings that advantage narrows, and fine texture is where AVIF tends to soften first. Fabric weave, brushed metal, skin texture on a beauty swatch: those are the details a premium brand pays a photographer to capture.
JPEG XL was built for stills. It holds fine detail at high quality and supports progressive decoding, so a large zoom image sharpens as bytes arrive instead of appearing all at once. It can also repackage an existing JPEG losslessly and smaller, which suits a catalogue of thousands of supplier JPEGs nobody wants to re shoot or re export.
Our working rule on premium storefronts: AVIF for listing grids, cart thumbnails and anything under roughly 800 pixels wide. JPEG XL, where the browser accepts it, for the product detail gallery, the zoom layer and editorial hero imagery. JPEG or WebP as the universal fallback. Measure before you commit, because the crossover point shifts with each photo style.
What it means on Shopify Plus and Magento Hyvä
On Shopify Plus, the CDN decides the format, and today it does not serve JPEG XL. Shopify's image_url documentation says the CDN detects client support for formats such as WebP and AVIF and picks one automatically. In our own test on October 8, a storefront image requested with a header that accepts JPEG XL, AVIF and WebP came back as WebP. Requested with JPEG XL as the only modern option, it came back as JPEG. Liquid themes and Hydrogen storefronts should change nothing yet. When Shopify adds JPEG XL to its negotiation, the gain arrives for free, and there is no reason to fight the CDN with self hosted image files in the meantime.
On Magento Hyvä, the format is your decision, which is both the opportunity and the work. Magento's core Catalog and Cms modules only whitelist jpg, jpeg, gif and png for uploads, so JPEG XL belongs in the delivery layer, not in the admin. Two patterns work. Generate JPEG XL variants at build or cache time next to the resized product images and serve them through a <picture> element with a JPEG XL source, an AVIF source and a JPEG fallback. Or negotiate at the edge, with an image CDN or a reverse proxy reading the request's Accept header. Hyvä's lean templates make the first pattern easy to add in the gallery and product card templates without touching any JavaScript.
Whichever route you take, watch the Vary header. A cache that ignores Accept will happily serve a JPEG XL file to a browser that cannot decode it, and that shows up as a broken gallery on a customer's older phone, not in your monitoring.
What we would change this quarter
Run a format bake off on your own catalogue before adding a third image format to the pipeline. On the storefronts we build, that means four steps.
- Pick 50 representative product images: a white background packshot, a lifestyle shot, a texture close up and a hero banner, at the widths your theme actually requests.
- Encode each as AVIF and JPEG XL at matched visual quality using a perceptual metric such as SSIMULACRA 2 or Butteraugli, not a fixed quality number, then compare bytes.
- Check Largest Contentful Paint on the product page in Chrome 155 with each variant. Smaller is not automatically faster if decode time rises on mid range Android hardware.
- Ship JPEG XL only where it wins by a clear margin, usually the gallery and zoom, and keep the fallback chain in place.
For merchants selling across Southeast Asia, where a large share of traffic runs on mid range Android phones over mobile data, the bytes saved on a five image product gallery are real money in conversion. The format is not the strategy, though. Correct sizes, lazy loading below the fold and a sane cache policy still deliver more than any codec swap.