Google brings JPEG XL back to Chrome
Google announced JPEG XL decoding starting with Chrome 155 after its earlier experiment was removed.
Google announced JPEG XL decoding starting with Chrome 155 after its earlier experiment was removed. This October 7 edition examines developer feedback, the new Rust decoder, competing compression claims and deployment fallbacks, then looks at OpenAI's newly published mathematical proof artifacts and an ESP32-C3 DNS sinkhole's hash-in-flash design.
Read the written edition (English) ↗
What this video covers
- The Chrome announcement was published October 6, 2026 and names Chrome 155. It does not establish that every website visitor already runs a supported version.
- Google credits persistent developer feedback and the Interop process. The jxl-rs decoder uses Rust and optimized vector operations, while small vetted unsafe areas and the browser sandbox remain.
- Google's advertised 30–50% compression improvement uses JPEG as its baseline. Actual savings depend on images, encoder settings and visual quality.
- Gianni Rosato's September encoder comparison favors AVIF across its tested lossy-fidelity range. He develops competing AVIF tools; his result and Google's JPEG-baseline claim measure different comparisons.
- Compare formats on representative images and keep compatible fallbacks. JPEG XL also supports reversible, lossless transcoding of existing JPEG files.
- OpenAI released 722 manuscripts grouped into 372 families, with varied verification and many Lean formalizations. The model remains unreleased, and Pro-equivalent compute figures are neither a retail price nor an elapsed-time guarantee.
- The ESP32-C3 creator reports approximately 50 KB RAM use by storing sorted domain hashes in flash. DNS-level blocking has same-domain and alternative-resolver limitations; hash collisions can overblock. Hardware results were not independently measured for this episode.
Transcript
Why is Chrome bringing JPEG XL back?
0:00 You probably think Google buried JPEG XL. Chrome is bringing it back, after removing experimental support, and Rust helped it get through the door. In this video, why did Google reverse course? And should you change your image pipeline? It's Wednesday, October seventh, and this is The Daily Diff. Keep one detail in mind. Your existing JPEGs have a way into this comeback.
0:20 On Tuesday, Google announced JPEG XL decoding starting with Chrome one fifty five. Today the announcement climbed Hacker News, alongside OpenAI's mathematical proof dump and a two dollar board that blocks advertising domains. Chrome's earlier experiment ended in twenty twenty three.
Why did the rejected format get another chance?
0:35 Google's explanation included insufficient ecosystem interest, which is awkward when the biggest browser controls whether the ecosystem can actually use your thing. The new post credits persistent developer feedback, including the Interop process. The people asking for this kept asking, and Google now points to browser tests intended to make the format behave consistently. The announcement credits contributors including Helmut Januschka.
0:57 Sometimes the most effective roadmap is refusing to close the issue.
What changed inside the decoder?
1:01 The biggest implementation change is a decoder called jay ex ell R S, written in Rust. Image decoders ingest complicated files supplied by strangers, which makes them a spectacular place to accidentally trust the internet. Rust helps prevent classes of memory errors before they become browser vulnerabilities. Google still keeps the sandbox, and the implementation still contains small, carefully reviewed unsafe areas. Security gets layers, because reality keeps finding the seams.
1:27 Google says fuzzing and AI code review found no memory safety bugs in this decoder's history. That's a useful report from the team shipping it. Future attackers are unlikely to accept the blog post as a binding contract. First question answered. Developer pressure and an optimized Rust decoder reopened the door. Google reversed a decision with engineering behind it, which is allowed even on the internet. Now the slide deck benchmarks.
Do the smaller files beat AVIF?
1:48 Google advertises thirty to fifty percent better compression than JPEG. Smaller downloads can help your users and bandwidth bill, but that range depends on what you encode and how you compare quality. Compression engineer Gianni Rosato published a September comparison where modern avif encoders beat JPEG XL across his tested fidelity range. He works on competing avif tools, so keep that incentive beside the graphs. These comparisons use different baselines.
2:12 Beating old JPEG leaves room for avif to win a workload. Google itself recommends trying both formats, which is unusually practical advice for a launch announcement. JPEG XL's other attractions include high dynamic range, lossless images and fine grained progressive decoding. The community publishes interactive demos for exploring the format. Your audience can see a useful picture while the rest arrives. For deployment, keep a fallback image, and verify support in the browsers your
2:37 customers actually run. The announcement names Chrome one fifty five. That gives you a target version, and your analytics tell you when your audience gets there. Second question answered. Test your real images before changing the pipeline, and preserve the compatibility path. An image format saving bytes is useful. A migration that hides your checkout button is an expensive interpretation of minimalism. Meanwhile, OpenAI published mathematical manuscripts and supporting
What did OpenAI actually publish?
3:00 proof artifacts on Tuesday. The repository contains seven hundred twenty two manuscripts, grouped into related families. The headline count includes companion arguments and alternative proofs, so read what each paper actually claims. Many have formal proofs in Lean, which lets a computer check mathematical deductions. Others still await formalization, and OpenAI explicitly warns that
3:21 some unformalized results could have issues. The repository hands researchers material they can inspect and challenge. The model remains unreleased. OpenAI says each result used roughly three hours of equivalent ChatGPT Pro thinking compute on average. That describes computational effort. It gives you neither a wall clock guarantee nor a retail price for producing a
3:40 theorem. The release follows consultation with an independent mathematics advisory group, and includes a revision and citation process. Academia gets a new pile of homework, plus the much more useful ability to point at the exact page that needs fixing. The Lean maintainers recommend compiling small portions at a time. Even a mathematical breakthrough eventually meets the ancient enemy of software, getting the build to finish.
How does a two dollar board block domains?
4:03 Finally, an open source DNS ad blocker runs on a tiny two dollar microcontroller board. The creator's trick is storing sorted domain hashes in flash, so the blocklist doesn't have to live in scarce working memory. The project reports roughly fifty kilobytes of RAM use. It looks up a requested domain in the flash table, blocks a match and forwards other queries upstream. Your router can acquire a tiny bouncer with a very specific guest list. DNS filtering works at the domain level.
4:28 Ads served from the same domain as useful content can slip through, and clients using another resolver can bypass it. Keep your expectations smaller than the board, which is a demanding size target. And the detail about your existing JPEGs?
Can your existing JPEGs join the comeback?
4:40 JPEG XL supports lossless JPEG transcoding, with a path to reconstruct the original JPEG. That gives an old image archive a migration option without another generation of quality loss. Test the storage and delivery tradeoffs. If you'd rather read this than hear me say it, the diff lands in your inbox every morning, free at the daily diff dot dev, link below.
Why would I ship the decoder and test the migration?
4:58 So today's verdict, SHIP IT. I'd ship the additional decoder because browser support gives developers a real choice, and I'd test the migration on our own images. Subscribe, hit the bell, and tell me in the comments if you'd have stamped it differently. And that's the diff for today. I'm Niko from Axrisi. Merge responsibly.
Sources
- Shipping JPEG XL in ChromeChrome for Developers
- JPEG XL prototype and November 2022 removal discussionChromium Blink developers
- Contemporaneous JPEG XL deprecation commentaryFree Software Foundation
- The case against JPEG XL — competing-encoder benchmarkGianni Rosato
- JPEG XL FAQ and reversible JPEG transcodingJPEG XL community
- HTML picture element and fallback selectionMDN Web Docs
- Progressive loading demoJPEG XL community
- Distance versus effort visualizerJPEG XL community
- Sharing AI progress in mathematicsOpenAI
- Mathematical manuscripts and proof artifactsOpenAI on GitHub
- Lean formalization library build notesOpenAI on GitHub
- ESP32-C3 hash-in-flash DNS ad blockerM-Abozaid on GitHub



