Two years after Google stripped JPEG XL from Chromium, the format is back. Chrome 155, released in early October 2026, ships decoding support for .jxl images by default — and this time the decoder is written in Rust. Firefox, meanwhile, has slipped to version 158.
TL;DR: Chrome 155, released in early October 2026, ships decoding support for JPEG XL (.jxl) by default, closing a years-long gap after Google removed the format. Coverage notes the decoder is written in Rust with memory safety prioritized, while Firefox support slipped to version 158 — so developers should keep fallbacks in place for now.
What Exactly Ships in Chrome 155 for JPEG XL?
Chrome 155 enables JPEG XL decoding by default, meaning the browser can display .jxl images without any flags, experiments, or configuration. The stable release, identified as version 155.0.8059.40 in the official build, started rolling out in early October 2026, with coverage from GIGAZINE, Neowin, and DigitBin all confirming the rollout.
The key word here is “decoding.” Chrome can render JPEG XL images served by websites. This is the foundation any format needs before adoption becomes realistic.
The announcement on Chrome for Developers states plainly: “We’re excited to announce that Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155.” JPEG XL is described there as a next-generation image format designed to meet the needs of modern imaging.
It is not just Chrome 155 getting attention this cycle. The same release also enables quantum-resistant cryptography, and DigitBin’s coverage adds post-quantum WebCrypto algorithms and digital credential issuance to the changelog. Wallet IDs appear in that roundup as well. But the image format is the headline change for web developers.
So what should you actually do? Verify your browser version, check that your CDN serves JPEG XL correctly, and keep fallbacks in place while other browsers catch up.
Why Did Google Drop JPEG XL in the First Place — and Why Bring It Back?
Coverage of the Chrome 155 release consistently frames JPEG XL support as a return, not a debut. The format was removed from Chromium years ago, and today’s release closes that gap. As the WindowsForum report puts it, Chrome 155 now decodes JPEG XL images by default — ending a long period in which the format’s browser story was defined by absence.
Why does a browser re-adding a decoder matter so much? Browser support has always been the gatekeeper for image formats. WebP became ubiquitous once every major engine shipped it. AVIF followed the same path. JPEG XL, despite strong technical credentials, never cleared that hurdle in Chromium — and without Chromium, the web’s dominant rendering engine, publisher adoption stalled.
The reversal suggests the calculus changed. A Rust-based decoder, discussed in the next section, addresses concerns that likely weighed on the original decision. The Chrome for Developers announcement describes JPEG XL as designed to meet the needs of modern imaging, which reads as a renewed commitment rather than a courtesy flag.
Should developers treat this as a signal? Caution is still warranted. Firefox support slipped to version 158, and the WindowsForum coverage explicitly recommends keeping fallbacks and verifying browser and CDN support. The gate has opened. It has not swung wide.
How Does the Rust Decoder Change the Security Picture?
The decoder behind Chrome’s JPEG XL support is written in Rust, with memory safety prioritized, according to coverage of the release. That detail matters more than it might first appear.
Image decoders are historically one of the riskiest components in any browser. They parse complex, attacker-controlled binary data from the open web. A single flaw in a decoder can translate directly into a drive-by exploitation vector, which is why browser vendors obsess over decoder hardening, fuzzing, and sandboxing.
Rust changes the starting conditions. Its ownership model eliminates entire classes of memory bugs — buffer overflows, use-after-free, dangling pointers — at compile time rather than relying on developers to avoid them. For a component whose sole job is parsing untrusted files, that is a meaningful shift in the default risk profile.
The GeekNews summary of the Chrome release highlights exactly this: decoding support with better compression and HDR support, delivered via a Rust decoder that prioritizes memory safety. The emphasis is deliberate.
Does Rust make the decoder bulletproof? No. Rust code can still contain logic errors, and the ecosystem around any decoder matters. But shipping a web-facing image decoder in a memory-safe language is a defensible engineering choice, and it stands in contrast to the C and C++ codebases that dominate legacy codec implementations. Security reviewers will be watching how this holds up in practice.
What Does JPEG XL Offer Over Traditional JPEG?
JPEG XL is positioned as a next-generation replacement for the aging JPEG standard, and the coverage of Chrome 155 points to two concrete advantages: better compression and HDR support.
The compression story is the easiest to grasp. Sources describe JPEG XL as offering improved compression — meaning smaller files at equivalent visual quality, or visibly better images at the same file size. For image-heavy websites, bandwidth is cost, and cost compounds at scale.
HDR support addresses the display side. Modern screens increasingly handle high dynamic range content, and legacy JPEG simply has no mechanism for it. JPEG XL’s support for HDR, noted in the release coverage, means a single format can serve both conventional and HDR pipelines.
Beyond those headline features, what does the format bring to day-to-day web work?
- Smaller image payloads for equivalent quality, reducing page weight
- Native HDR support for modern display hardware
- A .jxl file format designed for web delivery
- Decoding now enabled by default in Chrome 155
- A memory-safe Rust decoder in Chrome’s implementation
- A migration story for publishers currently standardizing on JPEG
The traditional JPEG has reigned for over three decades. Its successor’s browser moment may finally have arrived.
Is JPEG XL the only modern contender? No — AVIF and WebP both ship widely. But JPEG XL’s combination of compression gains and HDR support, now backed by default decoding in the most-used browser, gives publishers a serious option to evaluate.
What About Firefox and Other Browsers?
Firefox support has slipped to version 158, not 157 as some reports claimed. According to coverage at WindowsForum, an earlier claim that Mozilla would ship JPEG XL in Firefox 157 was wrong, and the format is now expected to arrive in version 158 instead. That means Chrome 155 reaches users first, and for a window of time Chrome will be the only major Chromium-based browser with the decoder enabled by default.
For site owners, this gap matters. If a visitor runs Firefox 157 or older, a bare .jxl file will simply fail to render. Sources covering the release consistently stress the same practical advice: keep fallbacks in place and verify both browser and CDN support before relying on JPEG XL anywhere on a production page. The decoder itself is implemented in Rust, a detail highlighted in coverage of the Chrome release, with a focus on memory safety in the parsing code. Until Firefox 158 lands, content negotiation — serving JPEG XL only to browsers that advertise support — remains the safest route. One version number is doing a lot of work here.
How Should Web Developers Roll Out JPEG XL Images?
Roll out JPEG XL with fallbacks first, native support second. Chrome 155 ships decoding support for the .jxl format by default, as announced on the Chrome for Developers blog, but shipping the decoder in one browser is not the same as universal availability. The WindowsForum report explicitly recommends that developers keep fallbacks and verify browser and CDN support — that is the core rollout guidance from the sources.
A sensible checklist looks like this:
- Serve JPEG XL through content negotiation, not as the only source
- Keep a JPEG or WebP fallback for browsers without the decoder
- Test that your CDN actually passes .jxl files through unmodified
- Verify the MIME type is configured correctly on the server
- Watch for Firefox 158 before removing any fallback logic
- Confirm encoding tooling produces files your pipeline can manage
- Monitor analytics to see what share of visitors can actually decode the format
None of the sources report concrete compression savings numbers for typical web imagery, so avoid promising specific bandwidth wins to stakeholders yet. The Chrome blog describes JPEG XL as a next-generation format designed to meet modern image needs, with better compression and HDR support noted in coverage. Validate on your own assets. Measured results will always beat assumptions.
What Else Arrives in Chrome 155 Beyond Images?
Two other changes ship alongside JPEG XL in Chrome 155: post-quantum cryptography and digital credential features. According to GIGAZINE, the stable release enables quantum-resistant cryptography, meaning Chrome’s cryptographic stack gains algorithms designed to resist attacks from future quantum computers. DigitBin’s summary of the release adds that post-quantum WebCrypto algorithms are part of the rollout, extending that protection to web applications using the browser’s crypto APIs.
The second addition is digital credential issuance. DigitBin reports that Chrome 155 introduces support for wallet IDs and digital credential issuance, tying the browser more closely to verifiable digital identity documents. Combined with the image format work, this makes 155 an unusually busy release for a stable channel update.
Why bundle these together? The common thread is modernization: image codecs built for current display hardware, cryptography built for threats that have not fully materialized, and identity features built for a shift away from physical documents. One browser version, three fronts. Sites and enterprises testing upgrades should treat all three as part of the same evaluation, since enabling one Chrome 155 deployment exposes users to all of these changes at once.
Does This End the AVIF vs JPEG XL Debate?
No — the sources do not frame Chrome 155 as settling anything. What they do establish: Chrome now decodes JPEG XL by default, the decoder is written in Rust with a memory-safety focus, and the format brings better compression and HDR support as noted in GeekNews coverage of the release. That is a significant platform win for JPEG XL after years in which support questions kept the format on the sidelines.
But the practical picture still depends on reach. WindowsForum’s report stresses that developers should keep fallbacks precisely because browser support remains uneven, with Firefox not expected until version 158. AVIF’s status relative to JPEG XL is not addressed in the provided sources, so no comparison of adoption, compression efficiency, or ecosystem support can be responsibly drawn here.
What can be said is this: JPEG XL now has native decoding in the world’s dominant browser, and that removes the single biggest technical objection to using it at all. The debate shifts from “can browsers display it” to “which formats earn their encoding and storage costs per site.” For now, serving both formats where it makes sense remains a defensible strategy. Let your own measurements decide.
What Should Site Owners Check Before Serving .jxl Files?
Check four things before .jxl files reach production: browser coverage, CDN behavior, MIME types, and fallbacks. The WindowsForum coverage of Chrome 155 distills the rollout advice into exactly two imperatives — keep fallbacks and verify browser and CDN support — and each of these checks maps onto that guidance.
Start with browsers. Chrome 155.0.8059.40 is the first stable build with the decoder enabled, so any analytics segment showing older Chromium versions or pre-158 Firefox cannot be assumed to render the format. Second, CDNs: some image optimization layers transform or reject unrecognized formats, and a transcoding middlebox can silently strip your JPEG XL gains. Third, server configuration — an incorrect MIME type can break loading even in a capable browser. Fourth, always provide a fallback path so a failed decode never means a broken page.
A quick pre-launch review:
| Check | What to verify | Risk if skipped |
|---|---|---|
| Browser support | Visitors on Chrome 155+ only served .jxl | Broken images for others |
| CDN passthrough | .jxl delivered without re-encoding | Lost compression benefit |
| MIME type | Correct type configured server-side | Load failures |
| Fallbacks | JPEG/WebP served via negotiation | Degraded experience |
Test on the actual stable build, not canary assumptions. Then ship gradually and watch error rates.
Frequently Asked Questions
Which Chrome version supports JPEG XL?
Chrome 155 is the first stable version with JPEG XL decoding support, per the Chrome for Developers blog. The stable build shown in release coverage is version 155.0.8059.40, and the decoder is enabled by default rather than behind a flag.
Is Firefox shipping JPEG XL in version 157?
No. WindowsForum’s report states that the claim of Firefox 157 shipping JPEG XL was wrong, and support is instead expected in Firefox 158. Until that version ships, Firefox users need sites to serve fallback image formats.
Does Chrome encode JPEG XL images or only display them?
The sources describe Chrome 155 as shipping decoding support — the ability to display .jxl images. Nothing in the provided coverage states that Chrome encodes or exports JPEG XL files, so encoding remains a task for external tooling.
What should developers do while browser support varies?
Keep fallbacks in place and verify both browser and CDN support, which is the explicit recommendation in coverage of the Chrome 155 release. Practically, that means content negotiation to serve .jxl only to capable browsers and a JPEG or WebP path for everyone else until Firefox 158 arrives.
Summary
Chrome 155 marks the moment JPEG XL decoding becomes a default browser capability, but the rollout story is only beginning.
- Chrome 155 stable ships JPEG XL (.jxl) decoding by default, with the decoder written in Rust with a memory-safety focus
- Firefox support slipped to version 158; earlier reports of a Firefox 157 ship were wrong
- The same release enables quantum-resistant cryptography and adds digital credential issuance with wallet IDs
- Developers should keep fallbacks and verify browser and CDN support before serving .jxl files in production
- No concrete compression-savings figures appear in the sources, so validate benefits on your own assets
If you manage a content-heavy site, now is the time to test JPEG XL in a staging environment — with fallbacks intact — and prepare for the moment Firefox 158 closes the support gap.