Google is bringing JPEG XL back to Chrome. Its October 6 announcement names Chrome 155 as the decoding milestone and describes a new Rust implementation. For developers responsible for image compression, that creates another format to evaluate, alongside the browser compatibility work that always comes with changing what you serve.
TL;DR
- Chrome 155 is the announced target. Check the versions your visitors actually use before changing production delivery.
- Google credits persistent developer feedback and a new optimized Rust decoder. The browser sandbox remains, and the implementation contains small reviewed unsafe areas.
- Google's advertised compression improvement compares JPEG XL with JPEG. A separate AVIF developer's benchmark uses a different comparison and favors AVIF in his tested range.
- JPEG XL supports reversible transcoding of existing JPEG files. That gives archives a migration option worth measuring.
- My verdict is SHIP IT for additional browser choice. A production migration still needs representative images, quality checks and a working fallback.
Why JPEG XL is returning to Chrome
The history makes this announcement interesting. Chrome previously supported JPEG XL experimentally, then ended that experiment. In the November 2022 Blink discussion, Jim Bankoski wrote that the team had decided to stop the experiment and remove its associated code. The Free Software Foundation's contemporary commentary records the February 2023 deprecation and quotes the ecosystem-interest rationale.
That was an awkward feedback loop. Developers need browser support to deploy a format, while browser teams want evidence that developers will deploy it. The largest browser can substantially influence how much of that evidence ever appears. The joke writes itself, although the sources do not establish a secret plot to sabotage the format.
Google's new post explicitly credits persistent developer feedback, including work through the Interop process. It also credits contributors including Helmut Januschka. The requests kept arriving, and the implementation changed. Sometimes the most effective roadmap is refusing to close the issue.
The useful lesson for a web team is about the level of certainty in the announcement. We have a named Chrome milestone and a published engineering explanation. We still need to know what versions our customers run. An announcement date and a visitor's installed browser version answer different questions. Treat the milestone as an input to your compatibility checks.
What the Rust decoder changes
Google describes the new decoder as jxl-rs, with optimized vector operations through its jxl_simd abstraction. A decoder takes a supplied image file and turns it into pixels. Every complex parsing rule is another place where malformed input might exercise behavior the implementation did not expect. Image files arrive from strangers, which makes this an especially useful place for memory-safety defenses.
Rust helps prevent classes of memory errors. The Chrome post describes fuzzing and AI code review and reports that Google found no memory-safety bugs in the decoder's history. That is a concrete report from the team shipping the implementation. Its scope matters: it describes the team's findings, rather than establishing a guarantee about every future input or vulnerability.
The implementation also retains small, carefully reviewed unsafe areas. Rust's safety properties require attention to the code that operates outside those guarantees. Google keeps the sandbox as another layer. Those details belong beside the headline about Rust because they explain the actual security posture: use stronger language-level protections, review the exceptions and preserve isolation.
For developers considering the format, this explains why the comeback involves engineering work as well as sustained demand. It gives us a better question to ask than whether a file extension is fashionable. Which implementation will decode the files, what protections surround it, and which customers can use it? The launch post supplies part of that answer. Your browser inventory supplies another part.
Image compression: JPEG XL versus AVIF needs a fair baseline
Google advertises thirty to fifty percent better compression than JPEG. Smaller transfers can reduce bandwidth use and help users download pages. The range still depends on the content, encoder settings and how quality is compared. I did not run a local encoder benchmark for this episode, so that number remains Google's claim.
There is an instructive counterexample in Gianni Rosato's September comparison. His modern AVIF encoders beat JPEG XL across the tested lossy-fidelity range. The article includes comparative plots and a decode-time comparison. Rosato develops competing AVIF tools, and that interest should travel with any summary of his findings.
The two claims can coexist. Google's comparison starts with JPEG. Rosato's comparison puts AVIF against JPEG XL. A format can improve on an older JPEG encoding while another format performs better on a particular workload. Turning either source into a declaration that one format wins every image would discard the methods that make the result useful.
Google itself recommends trying both formats. That is sensible advice for a launch announcement, and a useful constraint on the excitement. If your site is mostly product photography, evaluate product photography. If your key images are diagrams, use diagrams. The relevant outcome is the quality and transfer cost of the images your users see.
Keep quality judgments beside file sizes. A smaller file has limited value if it erases detail your customer needs. Record the settings used to make each candidate so the next person can reproduce the comparison. Compare several representative images before treating a striking example as the whole workload. These are suggested evaluation steps; the episode's graphs belong to their cited author.
Progressive decoding and existing JPEG archives
JPEG XL has attractions beyond a single lossy-compression comparison. The Chrome announcement discusses high dynamic range, lossless images and fine-grained progressive decoding. Progressive decoding can let a useful picture appear while additional data arrives. That capability is worth exploring separately from the final encoded size.
The community publishes a progressive loading demo and a distance-versus-effort visualizer. These are real interactive demonstrations. The visualizer's precomputed measurements belong to its documented setup; they are evidence you can inspect, with the machine and encoder context attached. They do not substitute for measurements of your own delivery path.
Existing JPEG archives get another option. The format FAQ describes lossless JPEG transcoding with a path to reconstruct the original JPEG. That means an archive can investigate JPEG XL without adding another generation of image-quality loss during that reversible operation.
Treat storage and delivery as separate decisions. You might find a useful archival workflow while continuing to serve a compatible format to some clients. Check the toolchain, preserve original material during evaluation and verify reconstruction on representative files. The community FAQ advocates for the format, so I use it here for the specific transcoding capability rather than importing its broad claims about comparative superiority.
How to evaluate a Chrome 155 migration
Start with your audience. Chrome 155 is a target version in the announcement; your analytics can show which browser versions visitors actually use. Build a compatibility picture around those visitors, including the clients important to your checkout, documentation or application. A format launch can create an opportunity before it covers your whole audience.
Next, make a small representative test set. Include images whose details matter and inspect the encoded results visually. Record quality settings, transfer sizes and decoding behavior. Run the comparison with the formats you already serve as well as the new candidate. A migration decision should improve an actual workload, rather than merely produce the smallest example in a launch thread.
Preserve a fallback. The MDN picture-element reference explains selecting sources by type and retaining an img fallback. Verify the behavior in the browsers you intend to support. A compressed image that fails to appear can hide information or a product, which is an expensive interpretation of minimalism.
Finally, separate reversible trials from widespread deployment. Try the candidate on a controlled set, check the compatibility path and compare the results against your current pipeline. Browser support gives developers more choice. Whether that choice pays off for your service is a measurement you can make after the launch excitement settles.
Also in this episode: proof artifacts and a tiny DNS blocker
OpenAI released mathematical manuscripts and proof artifacts. Its repository lists 722 manuscripts grouped into 372 families; related and alternative arguments affect those totals. Verification varies, with many Lean formalizations and some results still awaiting formalization. The model remains unreleased. The reported Pro-equivalent thinking compute describes effort, with no elapsed-time or retail-price guarantee.
The ESP32-C3 DNS blocker stores sorted domain hashes in flash to conserve working memory. Its creator reports a two-dollar board and roughly fifty kilobytes of RAM use. I did not test the hardware. Same-domain ads and clients using other resolvers limit DNS filtering; hash collisions can also overblock. The resurfaced project is a neat implementation to inspect with those limitations attached.
Verdict: SHIP IT
I'd ship the additional browser decoder because it gives developers a real choice. I'd measure the migration on our own images and preserve compatibility. Google returning to a format after developer feedback and implementation work is a useful outcome. Which format do you currently serve most often?
FAQ
Does every Chrome user have JPEG XL support now?
The announcement names Chrome 155. Check the versions your visitors run before assuming they can decode the format.
Does JPEG XL compress better than AVIF?
The cited Rosato comparison favors AVIF in its tested lossy-fidelity range. Google's advertised range compares JPEG XL with JPEG. Test representative images with a consistent quality comparison.
Does Rust make the decoder exploit-proof?
Rust helps prevent classes of memory errors. Reviewed unsafe areas and a sandbox remain, and Google's zero-found-memory-bugs report has the scope of its testing history.
Can JPEG XL preserve an existing JPEG?
The community FAQ describes reversible lossless JPEG transcoding and reconstruction of the original JPEG. Evaluate that workflow with the files and tools you intend to use.
Sources
- Chrome's JPEG XL announcement
- Blink's prototype and removal discussion
- Contemporary deprecation commentary
- Rosato's competing-encoder comparison
- JPEG XL FAQ
- Progressive loading demo
- Distance-versus-effort visualizer
- MDN picture element
- OpenAI mathematics announcement
- OpenAI proof repository
- ESP32-C3 DNS blocker
This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.
Top comments (0)