Chrome 155 decodes JPEG XL by default. Google's Chrome team published the announcement on October 6, 2026, the same day 155 reached the stable channel on desktop, Android and WebView. The decoder is jxl-rs, written in Rust. Four years ago the same browser deleted the format from its source tree.

The history is the part anyone serving images needs to know. Chromium added experimental JPEG XL decoding behind a flag in April 2021. In October 2022 a Google engineer posted comment 84 on the tracking bug and listed the reasons to drop it: experimental code should not sit behind a flag forever, there was "not enough interest" across the industry, and the format offered too little gain over existing ones to justify turning it on. The removal landed on December 9, 2022 and shipped in Chrome 110. The Register covered the fallout. Hundreds of people argued on the bug. Google did not move.

Then Apple shipped it. Safari 17 added JPEG XL decoding for still images in September 2023, and Apple's WebKit post claimed existing JPEGs could be recompressed without loss to about 20% smaller, with up to 60% savings when encoding from the original. Apple's build skipped progressive rendering and animation, so it was a partial answer. But it meant one of the three engines was already sending image/jxl in its Accept header to every server on the web.

Mozilla asked for a Rust decoder and got one

Mozilla declined to ship libjxl, the C++ reference decoder, and challenged the JPEG XL team at Google Research to write a safe one. That team wrote jxl-rs. Jake Archibald's Intent to Ship post on August 24, 2026 calls jxl-rs "the core of our JPEG XL support in Firefox" and names it as the thing that unblocked them.

The Chrome post by Luca Versari, Moritz Firsching and Philip Jägenstedt makes the same argument in Chrome's terms. Image decoders parse untrusted bytes from the network inside the renderer process. Decoders written in C and C++ have a long record of out of bounds reads, heap overflows and use after free bugs. Chromium's "rule of two" says code should not do more than two of these: handle untrusted input, run outside a sandbox, and be written in an unsafe language. A Rust decoder removes the third item. The team says it fuzzed jxl-rs, ran AI code review on it, and found no memory safety bugs in the project's history. A few unsafe blocks remain for SIMD, and the post credits Rust's stabilization of target_feature_11 with letting most of that SIMD code run without them.

So the reversal has little to do with the 2022 complaint about interest. The format did not change. Its compression numbers did not change. What changed is that Google decided a C++ image decoder it did not want to maintain was a liability, and a Rust one built by its own research arm was not. The announcement credits a 2026 Interop proposal and "sustained developer requests," which is a polite way of saying the bug tracker never went quiet.

Firefox is next. The default flip slipped from 157 to 158, now scheduled for October 13. The Firefox 158 beta notes already list it. By the middle of this month every major engine will decode JPEG XL, with Safari's build still the weakest on progressive loading.

What the format buys you

Chrome's post claims 30 to 50% better compression than JPEG at the same quality. The claims I trust more are the narrower ones. Lossless recompression of existing JPEGs runs around 20% smaller and is reversible, which is the one feature AVIF and WebP cannot match. Lossless mode beats optimized PNG by roughly 30% in the numbers people posted in the Hacker News thread, which drew 364 comments in a day. HDR, 32 bit float, layers and progressive decode are in the spec and in the decoder.

The case against it is in that thread too. AVIF wins on lossy compression at low bitrates, and a linked essay argues JPEG XL lossless decodes six times slower than WebP for a 10 to 13% size gain. Encoding is slow. One commenter running an image service measured AVIF at 10 to 20 times the CPU of WebP and expects JPEG XL to land near the same until hardware encoders exist. Nobody has shipped one. Adobe and Affinity both ship encoders that produce worse files than cjxl, so the tooling advice for now is to use the reference encoder and nothing else.

Chrome's own advice is to try both AVIF and JPEG XL and pick per use case. That is honest. It is also an admission that the web now has five current image formats: JPEG, PNG, WebP, AVIF and JXL. (Six if you count GIF.)

What changes on the server

If you run an image pipeline or a CDN config, the first thing that changed this week is the Accept header. Chrome 155 sends image/jxl in it, the same way it sends image/avif and image/webp. Any origin or edge that picks formats by Accept will see a new token from most of its traffic within a month. If you negotiate formats and did not add a jxl branch, nothing breaks. If you do add one, two old rules apply with more force:

  1. Send Vary: Accept, or your cache will hand a JXL to a browser that cannot decode it. Edge until it picks up 155, Chrome 145 through 154 with the flag off, and every Firefox before 158 will render a broken image.
  2. Normalize the Accept header at the edge before it becomes a cache key. Browsers send dozens of variants, and some CDNs ignore Vary entirely. Bucket to four values (jxl, avif, webp, legacy) and key on that.

Apache Traffic Server opened an issue on October 1 to add JXL to its webp_transform plugin for this reason, and it cites the Chromium, Gecko and WebKit source files that add the token. Expect the same ticket in every image proxy over the next quarter.

Do not transcode your archive this week. Firefox users are five days out, and Chrome's rollout to all desktop users takes a week or two past the stable date. Once Firefox 158 lands, the engines behind roughly nine of every ten page views will decode the format, and that is the point where serving JXL by default with a JPEG fallback starts paying for itself. The one job I would do now is a lossless JPEG to JXL pass on cold storage, since it is reversible byte for byte and the 20% cut is real. I spend my evenings on a backup server, so that number is the one I care about.

Format designers should read this as a rule. JPEG XL had a royalty free license, a finished ISO spec, a reference implementation and a loud fan base, and none of that got it into Chrome. A memory safe decoder did. Any new codec that wants into a browser now has to arrive with a Rust implementation, or wait for someone else to write one. I expect the next format fight to be about that, and I expect AV2 to learn the lesson faster than AVIF did.