For a long time, JPEG XL was a format without a majority on the web: Safari has displayed it since version 17.0 from September 2023 (WebKit), Chrome had pulled an early attempt hidden behind a flag, and Firefox held back. In October 2026 the situation changes. Chrome 155 decodes JPEG XL without a flag (Chrome for Developers), and Firefox 158 is scheduled to follow one week later (Mozilla Release Calendar). For online shops this raises a practical question: is another image format worth it next to AVIF and WebP, and if so, for which images? This article explains what JPEG XL can do, where it complements AVIF and WebP and where it does not, how to repack your existing JPEG inventory losslessly, and how to serve the format with a safe fallback – through the picture element or via the Accept header with a correctly configured cache.
Key takeaways
- Chrome decodes JPEG XL from version 155 without a flag (Chrome for Developers); the Chromium schedule lists 6 October 2026 for the stable release (Chromium Dash). Firefox 158 is scheduled for 13 October 2026 (Mozilla Release Calendar).
- Safari has displayed JPEG XL since version 17.0 (WebKit), but according to caniuse without progressive decoding and without animation (caniuse). With Firefox 158, all three major browser engines will then support the format for the first time, albeit not to the same extent.
- Existing JPEGs can be repacked losslessly into JPEG XL and restored bit for bit; on average they become 20 percent smaller (WebKit). For the LCP image, 57 percent of desktop pages use JPEG (HTTP Archive Web Almanac 2025).
- Safe delivery runs through the
pictureelement:image/jxlfirst, then AVIF, WebP and a JPEG as fallback. The browser skips every source whose type it does not support (MDN Web Docs) and takes the first match, not the smallest file. - Negotiating via the Accept header requires
Vary: Accept(IETF RFC 9110), and Safari does not announceimage/jxlthere (MDN Web Docs). Safari users then receive the fallback variant despite supporting the format. - Before switching the whole catalogue, run a pilot with one category: measure bytes per image, encoding time per effort level (libjxl: levels 1 to 10) and LCP per browser, then decide.
What changed in October 2026
Chrome 155 brings JPEG XL decoding to the Blink rendering engine, implemented with jxl-rs, a memory-safe decoder written in Rust (Chrome for Developers). The Chrome Platform Status entry lists shipping from version 155 on desktop and Android, with a rollout plan to enable it for all users (Chrome Platform Status). For the stable release, the Chromium schedule gives 6 October 2026 (Chromium Dash). In the source code of this version the feature is enabled by default, and Chrome announces the format in the Accept header of every image request: image/jxl comes before image/avif and image/webp (Chromium).
Firefox is following suit. The release notes for the Firefox 158 beta announce JPEG XL support (Mozilla), and Mozilla's release calendar lists 13 October 2026 for Firefox 158 (Mozilla Release Calendar). Safari has displayed JPEG XL since version 17.0 (WebKit), but with limitations: according to caniuse, progressive decoding and animated image sequences are missing (caniuse). With Firefox 158, all three major browser engines will then support the format for the first time, albeit not to the same extent. For Edge, caniuse does not list support yet, even though the browser is built on Chromium; check your own visitor statistics and a real browser to see whether and when Microsoft enables the feature.
The format is not new to Chrome. From version 91 to 109, an early decoder could be enabled via a flag, and with version 110 it disappeared again (caniuse). Chrome Platform Status briefly notes that the experimental implementation behind a flag was removed (Chrome Platform Status). The new attempt relies on a decoder written in Rust, which Chrome explicitly describes as memory-safe (Chrome for Developers). For shop owners, the outcome is what counts: a format that until now only Safari users got to see is now reaching Chrome users and, shortly, Firefox users. The following overview summarises the status of four common browsers; the version numbers come from caniuse data (caniuse), the Firefox date from Mozilla's calendar.
| Browser | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome (desktop, Android) | from version 32 | from version 85 | from version 155 |
| Edge | from version 18 | from version 121 | not supported up to version 154, later versions not yet recorded on caniuse |
| Firefox | from version 65 | from version 93 for still images, from 113 with animation | from version 158, scheduled for 13 October 2026 |
| Safari (macOS, iOS) | from version 14, on macOS from Big Sur | from version 16.4, partial from 16.1 | partial from version 17.0: no progressive decoding, no animation |
What JPEG XL brings technically
JPEG XL is standardised as ISO/IEC 18181 (JPEG Committee). Chrome Platform Status summarises its features as progressive decoding for improved perceived loading performance, wide colour gamut, HDR, high bit depth and animation (Chrome Platform Status). The JPEG committee also lists alpha channels, layers, thumbnails as well as lossless and progressive coding, and explicitly names e-commerce among the use cases (JPEG Committee). For product images, three properties really matter; the rest concern photography, image editing and specialised applications.
Lossless repacking
Existing JPEGs are converted to JPEG XL without recompression and can be restored bit for bit to the original file. No further generation with new artefacts is created.
Progressive display
The image builds up in stages while loading, so visitors see a usable preview earlier. According to caniuse, Safari does not support this part yet.
Colour gamut and HDR
Wide colour gamut, high bit depth and HDR are part of the format. That helps product ranges where colour accuracy matters, such as fashion, cosmetics or home furnishings.
The most important property for existing shops is lossless repacking. The JPEG committee explains that existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size, and that they can be restored into the exact same JPEG file (JPEG Committee). A server can therefore store a single JPEG XL file and serve browsers both with and without JPEG XL support from it. Apple puts the saving from repacking at 20 percent on average (WebKit), and at up to 60 percent compared to JPEG when encoding from the original (WebKit). Both figures are vendor statements without a disclosed image set; for your own product photos, only what you measure on them counts.
JPEG XL, AVIF or WebP: which fits when
JPEG still dominates the web. The HTTP Archive analysis for 2024 counts 32.4 percent of all images on mobile pages as JPEG, 28.4 percent as PNG and 12 percent as WebP (HTTP Archive Web Almanac 2024). AVIF reaches 1.0 percent (HTTP Archive Web Almanac 2024). The JPEG share has dropped noticeably, from 40 percent in 2022 to 32 percent in 2024 (HTTP Archive Web Almanac 2024). JPEG XL does not appear in the count because the Chromium-based crawler did not accept the format at the time.
For loading speed, the largest visible element matters most. On 85.3 percent of desktop pages and 76.0 percent of mobile pages it is an image (HTTP Archive Web Almanac 2025). Among these LCP images, JPEG leads with 57 percent of desktop pages, followed by PNG with 26 and WebP with 11 percent (HTTP Archive Web Almanac 2025); AVIF reaches 0.7 percent (HTTP Archive Web Almanac 2025). Anyone working on the file size of the LCP element is therefore usually dealing with a JPEG – and that is exactly where lossless repacking comes in. Our article on fetchpriority and Priority Hints describes further levers for the LCP image.
The format alone decides less than its name suggests. At the median, JPEG images on mobile pages come to 2.0 bits per pixel, AVIF to 1.4 and WebP to 1.3 (HTTP Archive Web Almanac 2024). That WebP is slightly ahead of AVIF at the median does not count against AVIF; it shows how strongly encoder settings and subjects shape the result. For a format decision, only measurements on your own images are useful, not averages from other people's inventories. The following table classifies typical starting points in a shop.
| Starting point in the shop | Obvious choice | Reasoning |
|---|---|---|
| Large inventory of product JPEGs | JPEG XL, repacked losslessly | smaller files without quality loss, original restorable bit for bit |
| New photos from high-quality originals | AVIF or JPEG XL, lossy | compare both formats on samples and decide per subject group |
| Logos, icons, graphics with text | SVG, otherwise lossless WebP or PNG | vectors scale without extra weight, photo formats help little here |
| Animated product views | short video instead of image animation | video encoding is designed for moving images, Safari does not display animated JPEG XL |
| Colour-critical ranges with HDR material | JPEG XL or AVIF | both formats carry wide colour gamut and high bit depth |
| Images without a pipeline, maintained by hand | WebP as the baseline | broad support, simple tools, little maintenance effort |
Repacking existing JPEGs losslessly
Lossless repacking is the lowest-risk way in, because it requires no decision about quality levels. The free reference implementation libjxl (libjxl), which the JPEG committee points to for part 4 of the standard (JPEG Committee), handles this out of the box: when the encoder cjxl receives a JPEG file, it applies lossless recompression by default, and the decoder djxl reconstructs the original JPEG file when the output file ends in .jpg (libjxl). Every conversion therefore stays reversible – an important argument against any lossy re-encoding, where artefacts add up from generation to generation.
# Repack a product JPEG losslessly into JPEG XL (default for JPEG input)
cjxl product-1600.jpg product-1600.jxl
# Cross-check: recover the JPEG from the JXL file and compare byte by byte
djxl product-1600.jxl check.jpg
cmp product-1600.jpg check.jpg && echo "bit-identical"
# Compare sizes in bytes
stat -c '%s %n' product-1600.jpg product-1600.jxlComputing time is the second point you should know before switching a catalogue. libjxl generally offers effort levels from 1 to 10, plus a level 11 as an expert option for lossless encoding; higher levels encode more slowly, use more coding tools and search more exhaustively (libjxl). For lossy encoding, the --distance parameter controls fidelity to the original in units of just-noticeable difference: 0 is lossless, and according to the documentation the most useful range is 0.5 to 3.0 (libjxl). For a catalogue with many thousands of image variants, it pays to measure the run time per level on a sample before scheduling the batch run. Otherwise the conversion competes for computing time with the server that is supposed to be delivering orders.
The cross-check belongs in the batch run
Delivery with a safe fallback
The most robust route into the front end is the picture element. It contains one or more source entries with a MIME type and, at the end, a regular img. If the browser does not support the given type, it skips the source (MDN Web Docs) and checks the next one; at the very end, the img with the JPEG applies. Apple recommends exactly this approach to deliver JPEG XL to supporting browsers while giving all others a fallback format (WebKit). Even so, the element is not widely used: picture appears on 9.3 percent of mobile pages (HTTP Archive Web Almanac 2024).
<picture>
<source type="image/jxl"
srcset="/media/shelf-800.jxl 800w, /media/shelf-1600.jxl 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<source type="image/avif"
srcset="/media/shelf-800.avif 800w, /media/shelf-1600.avif 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<source type="image/webp"
srcset="/media/shelf-800.webp 800w, /media/shelf-1600.webp 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<img src="/media/shelf-800.jpg"
srcset="/media/shelf-800.jpg 800w, /media/shelf-1600.jpg 1600w"
sizes="(min-width: 1024px) 50vw, 100vw"
width="800" height="800" fetchpriority="high"
alt="Oak wall shelf, front view">
</picture>The order is decisive. The browser takes the first source whose type it knows, not the smallest file. If JPEG XL is at the top, Chrome from version 155 and Safari from version 17.0 load the JXL variant (caniuse), even if an AVIF file of the same subject would be smaller. With losslessly repacked JPEGs this can happen, because repacking keeps the original JPEG compression while AVIF re-encodes lossily. A rule per image group therefore makes sense: the pipeline compares file sizes and only writes those formats into the picture element that actually save something compared with the next level. For the LCP image, keep fetchpriority="high" and no lazy loading, as described in our article on progressive image loading with LQIP.
Accept header, CDN and Vary
The alternative to the picture element is negotiation on the server. With every image request, the browser sends an Accept header listing the formats it accepts; the server or CDN delivers the matching variant under the same URL. Chrome 155 puts image/jxl at the top of this list (Chromium). Safari, by contrast, lists image/webp, image/png and image/svg+xml for images, but no image/jxl (MDN Web Docs), even though it can decode the format. Pure Accept negotiation therefore serves Safari users the fallback variant. For Firefox 158, too, you should check the header actually sent by a real browser before relying on it; the MDN overview so far lists image/avif and image/webp for Firefox, but not JPEG XL (MDN Web Docs).
If you negotiate via the Accept header, the cache has to be set up for it. RFC 9110 states that the Vary header expands the cache key required to match a stored entry (IETF RFC 9110). Without Vary: Accept, an intermediate cache can deliver the JXL variant to a browser that cannot display it. With Vary: Accept, each distinct Accept value creates its own entry; our article on cookies, Vary and the cache hit rate shows how much that can depress the hit rate. Many images travel via third-party hosts anyway: on mobile pages in 2024, 62 percent of images already came from a different domain than the page itself (HTTP Archive Web Almanac 2024). The image service or CDN then decides whether JPEG XL is generated, stored and correctly negotiated – a point we regularly check as part of our caching strategies for shops.
# Serves product.jpg.jxl instead of product.jpg when the browser announces image/jxl
map $http_accept $jxl_suffix {
default "";
"~*image/jxl" ".jxl";
}
server {
location ~* \.jpe?g$ {
types { image/jpeg jpg jpeg; image/jxl jxl; }
add_header Vary Accept;
try_files $uri$jxl_suffix $uri =404;
}
}Two pitfalls in negotiation
add_header, that block by default no longer inherits the add_header directives of higher levels (nginx documentation). Security and cache headers therefore have to be repeated there. Second: a CDN that ignores Vary: Accept or does not include the header in its cache key may deliver the wrong variant. Check both with two requests that differ only in the Accept header.Shop system, image pipeline and computing time
Whether JPEG XL reaches the shop rarely depends on the browser and more often on the chain before it. Check for every link whether it can read, write and pass on the format: the upload in the back end, the generation of thumbnails and size variants, the media storage, the CDN and the part of the template that writes the image URLs. Where a link is missing, there are two routes. Either the JXL variant is created outside the shop system in a separate processing step that places a JXL file next to every generated JPEG, or you wait until the shop system supports the format itself.
In Shopware and comparable systems, size variants are created on upload or via a console command. A separate step for JPEG XL starts afterwards: it looks for new or changed JPEG variants, repacks them losslessly, checks the reverse conversion and stores the file under a predictable name. The template only adds the JXL source to the picture element if the file exists. That keeps the shop working even if the step fails at some point – visitors then receive AVIF, WebP or JPEG. Computing time is spent once per image variant, not per request, provided the result is stored. Our Shopware performance page shows how we speed up shops beyond that; adjusting the templates is part of our front-end optimization.
- Select a category with typical product photos whose pages receive a meaningful number of visits.
- Repack all JPEG variants in this category losslessly and verify the reverse conversion bit for bit.
- Compare bytes per image for JPEG, JPEG XL, AVIF and WebP and set the order in the
pictureelement per subject group. - Deliver the variants and cross-check in several browsers which file is actually loaded.
- Observe field data for Largest Contentful Paint, separated by browser, over several weeks.
- Only then decide on the entire catalogue, the storage requirement and the computing time of the batch run.
Is the switch worth it? A sober calculation
Shops with a large JPEG inventory that has not yet been converted, or only partly converted, to modern formats benefit the most. Here, repacking saves transfer volume without anyone having to decide on quality levels, and the original is preserved. A second case is product ranges where colour accuracy or HDR material matters. The step brings less where AVIF and WebP are already delivered cleanly: JPEG XL then competes with formats that already play to their strengths, and the gain has to hold its own against another variant in storage, additional computing time and more testing effort.
Rule of thumb for the order
picture element is therefore a measurement decision per image group, not a question of principle about the format.Measure the effect where it occurs. Lab values show whether the right file is loaded and how large it is. Whether Largest Contentful Paint drops is only shown by field data, and separated by browser: only Chrome, Firefox and Safari users from the versions mentioned receive a JXL file at all, and the Safari users among them only via the picture element. A comparison across all visitors dilutes the effect and quickly leads to the conclusion that the switch achieved nothing.
How we approach a format switch
In our image optimization projects, we start with an inventory: which formats are delivered, which images form the LCP element and how the variants are created today. We then set up a pilot for one category, with lossless repacking, cross-check, picture cascade and clean cache behaviour. Only when field data shows an advantage do we extend the step to the catalogue. Where needed, we combine this with a performance analysis of the entire page build, because a smaller image helps little if the LCP element is held back by a late script or a slow server.
Our article on image optimization with WebP and AVIF summarises the basics of WebP, AVIF and responsive delivery. JPEG XL adds another level to this chain but does not replace it: work on image dimensions, srcset, lazy loading outside the visible area and fixed aspect ratios remains the foundation on which any new format can take effect.
Sources and data
image/jxl (Chromium). Safari does not list the format in its Accept header for images (MDN Web Docs) and would therefore receive the fallback variant. In addition, every negotiated response needs Vary: Accept so that intermediate caches do not mix up the variants (IETF RFC 9110).Related Articles
TYPO3 Performance: Caching and Load Times Under Control
How the TYPO3 page cache works, which settings switch it off, and how the cache hash, the backends and the deployment decide the load time of a page.
Finding and Removing Unused CSS for Faster Loads
How much CSS a page really needs, how to measure the unused share reliably and in which order to remove ballast without breaking the rendering.
Redirect Chains: The Hidden Delay Before the First Byte
Every redirect costs a round trip before the first byte. Learn how to detect HTTP, www and slug chains and reduce them to a single hop without losing SEO value.