How Real Is the JPEG XL Comeback — 8 Months After Chromium's Reversal, Verified From the Source

Introduction — "It's Back" and "You Can Use It" Are Not the Same Thing
A Quick Recap — What Happened in 2022
November 22, 2025 — The Reversal, Posted to That Same Four-Year-Old Thread
What Actually Landed in Chrome — Tracked Through Gerrit
Firefox — Same Decoder, Half a Step Behind
Safari and Interop 2026 — Where the Rest of the Puzzle Actually Stands
Status Table as of Today
The Practical Call — What to Do Now, and What Not To
Closing
References

Introduction — "It's Back" and "You Can Use It" Are Not the Same Thing

Starting in late November 2025, articles claiming "Chrome has decided to support JPEG XL again" circulated, followed in early 2026 by "JPEG XL landed in Chrome 145," and most recently by "it landed in Firefox 152 too." All of these are true to some degree. And if you take them at face value and ship .jxl to production, you will have an incident.

Image-format support is a topic where the gap between rumor and actual status is especially wide. "The code is in the tree," "it's behind a flag," "it's enabled by default on Nightly," and "it's enabled by default in release" are all different stages, but news headlines blur that distinction. So this post looks only at primary sources instead of articles — merged CLs on the Chromium Gerrit, the actual gates in the source tree, milestones in Bugzilla, and the browser vendors' official release APIs. It lays out exactly how far JPEG XL has come as of today (2026-07-17), and when practitioners should actually move.

The format itself (compression efficiency versus AVIF, features like lossless JPEG recompression) was covered in Image Formats in 2026 — AVIF / JPEG XL / WebP / HEIC / MozJPEG / QOI / Sharp / Squoosh Deep Dive, so here we ask only one question: is it landing in browsers?

A Quick Recap — What Happened in 2022

In chronological order:

In 2021, Chromium put an experimental libjxl (C++)-based decoder behind a flag and posted an Intent to Prototype thread on blink-dev.
In October 2022, a removal notice was posted to the same thread. The gist had three points: experimental flags aren't kept indefinitely, ecosystem-wide interest wasn't large enough to justify continuing the experiment, and the incremental gain over existing formats wasn't large enough to justify enabling it by default.
The code and flag were actually removed in Chrome 110. Per the official Chrome version history API, the stable rollout of 110 started on February 1, 2023.

For the three years that followed, this decision remained the loudest image-format debate on the Chrome issue tracker. Meanwhile, the outside world changed. Apple noted the addition of JPEG XL support in the Safari 17 release notes (September 2023) — and it remains, to this day, the only major engine that supports it enabled by default. Mozilla, in its official standards-positions document, kept the position itself neutral, but stated in the rationale that "the benefit isn't large enough to justify the cost of adding yet another C++ image decoder, but a memory-safe decoder would substantially cut that cost, and we would be willing to ship an implementation that meets our requirements." It's commonly reported that "Mozilla flipped to positive," but the registered position is still neutral today — "conditional openness" is the accurate description.

And something that fit that condition appeared: jxl-rs, a pure-Rust decoder built by the libjxl team. The repository itself describes it as "a work-in-progress reimplementation aiming for spec compliance, safety, and speed." That "work-in-progress" qualifier matters again later.

November 22, 2025 — The Reversal, Posted to That Same Four-Year-Old Thread

The reversal notice wasn't a new blog post — it was posted as a reply in the very same blink-dev thread where the 2021 Intent to Prototype had been posted. The author is Rick Byers, writing on behalf of the Chrome ATLs (Architecture Tech Leads). To summarize:

Things have changed since the last assessment — Safari shipped, Firefox updated its position, developer signals like bug stars, Interop proposals, and surveys keep showing up, and there has also been an announcement that JPEG XL is being added to the PDF standard.
Based on those signals: "we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder."
But enabling it by default requires a commitment to long-term maintenance, and once that and the usual shipping criteria are met, it will land in Chrome.

Parse that sentence closely and it isn't "we will do this." It's "if someone brings it, and commits to keeping it maintained, we'll ship it." Recall that the core argument for the 2022 removal was maintenance burden, and this is a consistent stance — the door was opened only on the condition that Chrome itself doesn't carry that burden. Understanding this structure is what lets you correctly read the pace of the eight months that followed.

What Actually Landed in Chrome — Tracked Through Gerrit

Drawing the timeline using only merged CLs and official schedules looks like this. All of it can be verified on the Chromium Gerrit.

2025-11-22  Conditional reversal notice posted to blink-dev (Chrome ATLs)
2025-12-10  jxl-rs vendored into third_party — CL 7201443, +73,908 lines
2025-12-28  JXL infrastructure added: enums and build flags
2026-01-08  JXL image decoder added, based on jxl-rs (reverted, then relanded 01-09)
2026-01-13  Decoder wired up + feature-flag gating + WPT tests added
2026-01-16  Cherry-picks begin onto the 145 branch tagged [M145]
2026-02-10  Chrome 145 stable (official chromiumdash schedule) — the JPEG XL
            decoder returns to a stable binary for the first time since M110
2026-02-24  DevTools integration (JXL-disabled emulation, host config exposed)
2026-01~04  jxl crate version rolls repeat, 0.1.4 → 0.4.3
2026-05-07  chrome://flags entry expiration extended to M152
2026-06-28  Stabilization fixes (truncated-file rendering, animation crashes, etc.) still landing

A few things are worth flagging here.

First, there are three layers of gating. Going by source, the compile switch is the gn arg enable_jxl_decoder, which defaults to true, so the decoder is included in official builds. But the runtime is controlled by blink::features::kJXLImageFormat, and as of today's main this base::Feature is FEATURE_DISABLED_BY_DEFAULT. The only way a user can turn it on is the enable-jxl-image-format entry in chrome://flags. In short, from Chrome 145 through 151 (the current stable), the decoder is in the binary but off by default.

Second, the "contributions welcome" model played out literally. The owner of this flag recorded in flag-metadata.json is not a Google employee but an external contributor (helmut@januschka.com). In fact, the first implementation, based on C++ libjxl, was scrapped after review feedback said "do it in Rust," and the process of rebuilding it on jxl-rs is laid out in the contributor's own retrospective post. The author's own measurements in that post (December 2025, after the jxl-rs community's 26 SIMD-optimization PRs) show that C++ libjxl was still faster on 2 of 3 test images (for example, on a 2048x2560 photo, jxl-rs took 198ms versus libjxl's 170ms), while jxl-rs was more than 3x faster on the remaining one. These are personal measurements on a handful of specific images, so they're hard to generalize, but they do support the general direction that "the Rust decoder isn't across-the-board faster yet."

Third, the shipping process hasn't even started. The Chrome status on the chromestatus entry is still "Proposed," and there is no Intent to Ship thread. In May, the flag's expiration was extended to M152, and per the chromiumdash schedule, 152 goes stable on August 25, 2026. That extension means "keep it flag-gated until then," not "ship it in 152" — extending a flag's expiration is routine housekeeping. The fact that CLs fixing things like partial rendering of truncated files and a crash when querying an animation's repeat count were still landing as late as late June says, more precisely, that this code is still in a "stabilizing" phase, not yet an "enable-by-default candidate" phase.

Firefox — Same Decoder, Half a Step Behind

Progress on the Firefox side can be pinned down precisely via Bugzilla milestones.

Bug 1986393 (opened 2025-09-02, FIXED, milestone 149): "Land initial jpegxl rust code with the pref off." Interestingly, this is more than two months ahead of Chromium's reversal notice — once Mozilla's own condition (a memory-safe decoder) was met, it had already been quietly moving first.
Bug 2016688 (FIXED, milestone 152): "Build jpeg xl code in beta/release builds too." Indeed, ESR 140's moz.configure still has the Nightly-only compile condition, while on the 152 release branch that condition is gone, so it compiles on every channel.
However, the default value of image.jxl.enabled in StaticPrefList.yaml is @IS_NIGHTLY_BUILD@. In other words, the Firefox 152 release build shipped on June 16, 2026 has the decoder compiled in, but the pref is off, and it only works if you turn it on manually in about:config. There's no mention of JPEG XL in the official 152 release notes — that's exactly the size of the gap between the headline "Firefox 152 supports JPEG XL" and the actual shipped state.

One notable fact: the decoder pinned by Firefox's Cargo.lock is jxl crate 0.4.3 — the same libjxl/jxl-rs that Chromium vendored. The two engines share the same third-party decoder implementation. Recall that one leg of the 2022 removal argument was "each browser shouldering one more C++ decoder to maintain" — the structure of that burden has itself changed. Now, safety and performance improvements to one repository flow into both browsers at once.

Of course, the list of unfinished work is right there in the source too. The tracking metabug 1539075 was opened in 2019 and has been ASSIGNED for seven years now (last activity two days before this post), a workaround for a 3x decoding slowdown on mac x86_64 is still outstanding (bug 2043091), and quality issues like getting color space recognized via a CICP enum instead of synthesizing an ICC profile (bug 2055224) are still being filed fresh this very week.

Safari and Interop 2026 — Where the Rest of the Puzzle Actually Stands

Safari isn't a variable in this story. It has supported JPEG XL by default since Safari 17 in September 2023, and it was also the first piece of evidence Byers's notice cited.

The one that needs more careful reading is Interop 2026. There's talk that "JPEG XL was included in Interop 2026," but per the official README, JPEG XL is an investigation effort, not a scored focus area. The document itself acknowledges that web-platform tests for it are currently sparse, sets this year's goal as "making this feature testable," and notes that even progressive rendering — something developers consider important — is still being debated in terms of when and how browsers should perform it. That means it's not at the stage of scoring interoperability; it's at the stage of building the scoring rubric itself. In practice, commits filling out tests in the jpegxl WPT directory have kept flowing on both Gerrit and Bugzilla in the first half of this year — the direction is right, but nobody has promised a finish line.

Status Table as of Today

Summed up, here is the state as of July 17, 2026.

                          Decoder Compiled   Default On   Manual Activation
Chrome 151 (stable)             O                X        chrome://flags's
                                                             enable-jxl-image-format
Firefox 152 (release)           O                X        about:config's
                                                             image.jxl.enabled
Firefox Nightly (154)           O                O        -
Safari 17+                      O                O        -

Intent to Ship (Chromium):      None (chromestatus status "Proposed")
Release default-enable schedule: Not announced by any engine
Interop 2026:                    investigation effort (not scored)

The statement "for the first time in three years, a JPEG XL decoder exists in the codebase of all three engines" and the statement "JPEG XL still doesn't render for the vast majority of web traffic" are both true at the same time. Holding both of these sentences together is what an accurate understanding of this topic looks like right now.

The Practical Call — What to Do Now, and What Not To

Start with what not to do right now. That is: switching the web image format you serve to users over to JPEG XL. Since it's not supported by default on Chrome-family browsers and release Firefox, shipping .jxl without content negotiation sends broken images to most users. There is a workaround via a WASM polyfill — the retrospective post's author built one that, by the author's own listing, is about 540KB after gzip — but bolting on a 540KB runtime to save a few dozen KB of image weight gets things backwards in most web-performance scenarios. Where a polyfill actually earns its keep is in niche viewer-type applications that already hold a large volume of JXL originals.

Here's what's worth doing right now. First, check whether your image pipeline already has <picture>- or Accept-header-based format branching. The same structure you built when moving from WebP to AVIF becomes the intake path for JXL as-is — it's just one more format added. Second, add the share of Accept: image/jxl in your CDN or origin logs as an observability metric. Safari users and users with the flag enabled are already sending it, and the day that share jumps in a step is the day some browser changed its default. Third, hang your decision signal on primary sources, not news. There are exactly two real signals — an "Intent to Ship: JPEG XL" thread appearing on blink-dev, and a commit that flips Firefox's image.jxl.enabled default to true without the Nightly condition. Until one of those two happens, everything else is just warming up.

One more thing worth adding: this case has a lesson that has nothing to do with the format itself. The 2022 removal wasn't about "poor quality" — it was about "not enough reason to take on the maintenance burden" — and the 2025 reversal wasn't produced by a benchmark, but by a change in the structure of that burden (a memory-safe shared decoder, plus external contribution, plus a maintenance commitment). When it comes to putting a feature into a browser, technical-superiority debates matter less than you'd think, and maintenance economics is the constant.

Closing

The accurate version of "JPEG XL is back" reads like this — Chromium opened the door with conditions attached, an external contributor's and the libjxl team's Rust decoder walked through that door, Firefox started shipping the same decoder one step ahead, and Safari never left in the first place. But as of July 2026, no engine has changed its release default, and none has a schedule to do so.

So the job right now isn't to switch — it's to observe. Get your format-branching structure in order, watch the Accept header, and wait for the one real signal that is Intent to Ship — that's the most honest position a practitioner can take on JPEG XL as of today.