Chrome 155 decodes JPEG XL natively through jxl-rs, a decoder rewritten in Rust

According to the dev.to write-up of Google's announcement, image decoders are among the most exploited attack surfaces in any browser. They parse complex binary data that comes straight off the network, and they run inside the process that renders the page ^[15]. C++ decoders have a long record of out-of-bounds reads, heap overflows and use-after-free bugs ^[16]. Chrome's first defence is process isolation, under what the team calls the rule of two ^[17]. The write-up describes the rule as treating a component that processes untrusted data, runs in a sandbox and is written in a memory-unsafe language as high risk by design. jxl-rs is written in Rust, so it fails the last of those conditions ^[17][1].

The scope is one format. Being the first also means the decoders Chrome already shipped for older formats are not complete memory-safe implementations ^[22].

Speed was a separate line of work. The announcement lists three: the Rust rewrite for security, performance work to match the C++ reference implementation, and Chrome's part in the interop process ^[11]. The write-up does not include benchmark figures for the libjxl comparison. I'd want them before trusting parity on my own traffic. For the claim to transfer, Google's test hardware and image sizes would have to resemble your users' phones and your product photos.

Google's compression figure needs the same treatment. The announcement says JPEG XL compresses 30 to 50 percent better than JPEG ^[4], and up to 50 percent smaller at the same visual quality ^[18]. On those numbers, a 200 KB JPEG would land between 100 and 140 KB ^[21]. For that to hold on a given site, its quality metric has to agree with Google's. Its images also have to resemble the photography and web content the JPEG committee designed the format for ^[19].

Chrome only decodes. It has no encoder for producing .jxl in the browser ^[9], so every file has to come from a server or a build step. The property operators should care about is reversible transcoding: an existing JPEG can be converted to .jxl and back without losing quality ^[4]. For browsers that cannot decode .jxl, an origin can in principle keep one .jxl copy and rebuild the original JPEG on request ^[23].

The 2022 removal drew a strong reaction from developers and photographers who had already adopted the format ^[20]. JPEG XL stayed a popular proposal in the interop process, in 2026 and in earlier years ^[14]. Rebuilding the decoder in a different language is a thorough way to close a long-running ticket. The version that came back has a new implementation and a security argument the flagged one did not have ^[13].