Skip to content
←

Split View: JPEG XL의 귀환은 어디까지 진짜인가 — Chromium 번복 후 8개월, 소스로 확인한 현재 위치

|

JPEG XL의 귀환은 어디까지 진짜인가 — Chromium 번복 후 8개월, 소스로 확인한 현재 위치

들어가며 — "돌아왔다"와 "쓸 수 있다"는 다른 말입니다

2025년 11월 말부터 "Chrome이 JPEG XL을 다시 지원하기로 했다"는 기사가 돌았고, 2026년 초에는 "Chrome 145에 JPEG XL이 들어갔다", 최근에는 "Firefox 152에도 들어갔다"는 이야기까지 나왔습니다. 전부 어느 정도는 사실입니다. 그리고 그대로 믿고 .jxl을 프로덕션에 배포하면 사고가 납니다.

이미지 포맷 지원 문제는 유독 소문과 실제 상태의 간극이 큽니다. "코드가 트리에 있다", "플래그 뒤에 있다", "Nightly에서 기본 활성이다", "릴리스에서 기본 활성이다"는 전부 다른 단계인데, 뉴스 제목은 이 구분을 뭉갭니다. 그래서 이 글은 기사 대신 1차 소스만 봅니다 — Chromium Gerrit의 머지된 CL, 소스 트리의 실제 게이트, Bugzilla의 마일스톤, 브라우저 벤더의 공식 릴리스 API. 오늘(2026-07-17) 기준으로 JPEG XL이 정확히 어디까지 왔는지, 그리고 실무자는 언제 움직여야 하는지를 정리합니다.

포맷 자체(AVIF 대비 압축 효율, 무손실 JPEG 재압축 같은 기능 비교)는 이미지 포맷 2026 딥다이브에서 다뤘으니, 여기서는 "브라우저에 실리는 중인가"라는 한 가지 질문만 팝니다.

짧은 복습 — 2022년에 무슨 일이 있었나

시간순으로 요약하면 이렇습니다.

  • 2021년, Chromium은 libjxl(C++) 기반의 실험 디코더를 플래그 뒤에 넣고 blink-dev에 Intent to Prototype 스레드를 올렸습니다.
  • 2022년 10월, 같은 스레드에 제거 공지가 올라왔습니다. 요지는 세 가지였습니다 — 실험 플래그를 무기한 유지하지 않는다, 생태계 전반의 관심이 실험을 계속할 만큼 크지 않다, 기존 포맷 대비 증분 이득이 기본 활성화를 정당화할 만큼 크지 않다.
  • 코드와 플래그는 Chrome 110에서 실제로 제거됐습니다. Chrome 공식 버전 이력 API 기준으로 110 스테이블 롤아웃 시작은 2023년 2월 1일입니다.

이후 3년간 이 결정은 크롬 이슈 트래커에서 가장 시끄러운 이미지 포맷 논쟁으로 남았습니다. 그 사이에 바깥 상황이 바뀌었습니다. Apple은 Safari 17 릴리스 노트(2023년 9월)에 JPEG XL 지원 추가를 명시했고 — 지금까지도 기본 활성으로 지원하는 유일한 메이저 엔진입니다. Mozilla는 공식 표준 입장 문서에서 position 자체는 neutral을 유지하되, 근거문에 "또 하나의 C++ 이미지 디코더를 추가하는 비용을 정당화할 만큼 이득이 크지 않지만, 메모리 안전한 디코더라면 그 비용이 크게 줄어들며 요구사항을 충족하는 구현이라면 출시할 의향이 있다"는 취지를 명시했습니다. 흔히 "Mozilla가 positive로 돌아섰다"고 알려져 있는데, 등록된 입장은 지금도 neutral입니다 — 조건부 개방이 정확한 표현입니다.

그리고 그 조건에 맞는 물건이 생겼습니다. libjxl 팀이 만드는 순수 Rust 디코더 jxl-rs입니다. 저장소 스스로 "규격 준수·안전·속도를 목표로 하는 진행 중(work-in-progress) 재구현"이라고 소개합니다. 이 "진행 중"이라는 단서는 뒤에서 다시 중요해집니다.

2025년 11월 22일 — 4년 전 그 스레드에 올라온 번복

번복 공지는 새 블로그 포스트가 아니라, 2021년 Intent to Prototype이 올라왔던 바로 그 blink-dev 스레드에 답글로 올라왔습니다. 작성자는 Rick Byers, Chrome ATL(Architecture Tech Leads) 명의입니다. 내용을 요약하면:

  • 지난 평가 이후 상황이 바뀌었다 — Safari가 출시했고, Firefox가 입장을 갱신했고, 버그 추천수·Interop 제안·설문 같은 개발자 신호가 계속 관측되며, PDF 표준에 JPEG XL이 추가된다는 발표도 있었다.
  • 이 신호들을 근거로: "we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder"(성능 좋고 메모리 안전한 JPEG XL 디코더를 통합하는 기여를 환영한다).
  • 단, 기본 활성화하려면 장기 유지보수에 대한 약속이 필요하고, 그것과 통상적인 출시 기준이 충족되면 Chrome에 실겠다.

문장을 뜯어보면 이건 "우리가 하겠다"가 아닙니다. "누가 해 오면, 그리고 계속 유지보수하겠다고 약속하면, 실어 주겠다"입니다. 2022년 제거의 핵심 논거가 유지보수 부담이었다는 점을 기억하면 일관된 태도입니다 — 부담을 지지 않는 조건으로만 문을 연 겁니다. 이 구조를 이해해야 이후 8개월의 진행 속도가 해석됩니다.

Chrome에 실제로 들어간 것 — Gerrit으로 추적

머지된 CL과 공식 일정만으로 타임라인을 그리면 이렇습니다. 전부 Chromium Gerrit에서 확인할 수 있습니다.

2025-11-22  blink-dev에 조건부 번복 공지 (Chrome ATLs)
2025-12-10  jxl-rs를 third_party에 벤더링 — CL 7201443, +73,908줄
2025-12-28  JXL 인프라 추가: enum과 빌드 플래그
2026-01-08  jxl-rs 기반 JXL 이미지 디코더 추가 (revert 후 01-09 reland)
2026-01-13  디코더 연결(wire up) + 피처 플래그 게이팅 + WPT 테스트 추가
2026-01-16  [M145] 태그가 붙은 145 브랜치 체리픽 시작
2026-02-10  Chrome 145 스테이블 (chromiumdash 공식 일정) — M110 이후
            처음으로 JPEG XL 디코더가 스테이블 바이너리에 복귀
2026-02-24  DevTools 통합 (JXL 비활성 에뮬레이션, host config 노출)
2026-01~04  jxl 크레이트 0.1.4 → 0.4.3 버전 롤 반복
2026-05-07  chrome://flags 항목 만료를 M152로 연장
2026-06-28  잘린 파일 렌더링·애니메이션 크래시 등 안정화 수정이 계속 머지되는 중

몇 가지 짚을 점이 있습니다.

첫째, 게이트는 세 겹입니다. 소스 기준으로 컴파일 스위치는 gn 인자 enable_jxl_decoder이고 기본값이 true라서 공식 빌드에 디코더가 들어갑니다. 하지만 런타임은 blink::features::kJXLImageFormat이 쥐고 있는데, 이 base::Feature는 오늘 main 기준 FEATURE_DISABLED_BY_DEFAULT입니다. 사용자가 켜는 방법은 chrome://flags의 enable-jxl-image-format 항목뿐입니다. 요컨대 Chrome 145부터 151(현재 스테이블)까지, 바이너리 안에 디코더는 있지만 기본값 기준으로는 꺼져 있습니다.

둘째, "기여 환영" 모델이 문자 그대로 실행됐습니다. flag-metadata.json에 기록된 이 플래그의 소유자는 Google 직원이 아니라 외부 기여자(helmut@januschka.com)입니다. 실제로 C++ libjxl 기반 1차 구현이 리뷰에서 "Rust로"라는 피드백을 받고 폐기됐고, jxl-rs 기반으로 다시 만든 과정이 기여자 본인의 회고 글에 정리돼 있습니다. 그 글에 실린 저자 자체 측정(2025년 12월, jxl-rs 커뮤니티의 SIMD 최적화 26개 PR 이후 기준)을 보면 테스트 이미지 3장 중 2장에서는 여전히 C++ libjxl이 빨랐고(예: 2048x2560 사진에서 jxl-rs 198ms 대 libjxl 170ms), 1장에서는 jxl-rs가 3배 이상 빨랐습니다. 어디까지나 특정 이미지 몇 장에 대한 개인 측정이라 일반화는 어렵지만, "Rust 디코더가 아직 전면적으로 빠른 건 아니다"라는 방향성 정도는 읽을 수 있습니다.

셋째, 출시 절차는 시작도 안 했습니다. chromestatus 항목의 Chrome 상태는 여전히 "Proposed"이고, Intent to Ship 스레드는 없습니다. 5월에 플래그 만료가 M152로 연장됐는데, chromiumdash 일정상 152 스테이블은 2026년 8월 25일입니다. 이 연장은 "그때까지는 플래그 상태로 둔다"는 뜻이지 "152에 출시한다"는 뜻이 아닙니다 — 플래그 만료 연장은 관례적인 하우스키핑입니다. 6월 말까지도 잘린 파일의 부분 렌더링 처리, 애니메이션 반복 횟수 조회 시 크래시 같은 것을 고치는 CL이 머지되고 있다는 사실이, 이 코드가 아직 "기본 활성화 후보" 단계가 아니라 "안정화 중" 단계임을 더 정확히 말해 줍니다.

Firefox — 같은 디코더, 반 발짝 뒤

Firefox 쪽 진행은 Bugzilla 마일스톤으로 정확히 짚을 수 있습니다.

  • 버그 1986393 (2025-09-02 생성, FIXED, 마일스톤 149): "초기 jpegxl rust 코드를 pref 꺼진 채로 랜딩". 흥미롭게도 Chromium의 번복 공지보다 두 달 이상 앞섭니다 — Mozilla는 자기 조건(메모리 안전 디코더)이 충족되자 조용히 먼저 움직이고 있었습니다.
  • 버그 2016688 (FIXED, 마일스톤 152): "beta/release 빌드에서도 jpeg xl 코드를 빌드". 실제로 ESR 140의 moz.configure에는 Nightly에서만 컴파일하는 조건이 남아 있고, 152 릴리스 브랜치에서는 그 조건이 사라져 모든 채널에서 컴파일됩니다.
  • 단, StaticPrefList.yaml의 image.jxl.enabled 기본값은 @IS_NIGHTLY_BUILD@입니다. 즉 2026년 6월 16일 출시된 Firefox 152 릴리스 빌드에는 디코더가 컴파일돼 있지만 pref가 꺼져 있고, about:config에서 수동으로 켜야 동작합니다. 152 공식 릴리스 노트에 JPEG XL 언급은 없습니다 — "Firefox 152가 JPEG XL을 지원한다"는 기사 제목과 실제 출하 상태의 간극이 딱 이만큼입니다.

주목할 사실 하나: Firefox의 Cargo.lock이 고정하는 디코더는 jxl 크레이트 0.4.3, 즉 Chromium이 벤더링한 것과 같은 libjxl/jxl-rs입니다. 두 엔진이 같은 서드파티 디코더 구현을 공유하는 겁니다. 2022년 제거 논거의 한 축이 "브라우저마다 C++ 디코더를 하나씩 더 짊어지는 유지보수 부담"이었다는 점을 떠올리면, 부담의 구조 자체가 달라졌습니다 — 이제 한 저장소의 안전성·성능 개선이 두 브라우저에 동시에 흘러갑니다.

물론 미완 목록도 소스에 그대로 보입니다. 추적 메타버그 1539075는 2019년에 열려 7년째 ASSIGNED 상태이고(마지막 활동은 이 글 이틀 전), mac x86_64에서 디코딩이 3배 느려지는 문제의 워크어라운드가 아직 남아 있으며(버그 2043091), 색공간을 ICC 프로파일 합성 대신 CICP enum으로 인식하게 하는 작업(버그 2055224) 같은 품질 이슈가 이번 주에도 새로 등록되고 있습니다.

Safari와 Interop 2026 — 나머지 퍼즐의 정확한 위치

Safari는 이 이야기에서 변수가 아닙니다. 2023년 9월 Safari 17부터 기본 지원이고, Byers의 공지가 첫 번째 근거로 꼽은 것도 Safari였습니다.

더 조심해서 읽어야 하는 건 Interop 2026입니다. "JPEG XL이 Interop 2026에 포함됐다"는 말이 도는데, 공식 README를 보면 JPEG XL은 점수가 매겨지는 focus area가 아니라 investigation effort입니다. 문서 스스로 현재 웹 플랫폼 테스트가 희소하다고 인정하고, 올해 목표를 "이 기능을 테스트 가능하게 만드는 것"으로 잡았으며, 개발자들이 중요하게 여기는 progressive rendering조차 브라우저가 언제 어떻게 수행해야 하는지 아직 논쟁 중이라고 적고 있습니다. 상호운용성 점수를 매기는 단계가 아니라, 채점 기준표를 만드는 단계라는 뜻입니다. 실제로 올해 상반기 Gerrit과 Bugzilla 양쪽에서 jpegxl WPT 디렉터리에 테스트를 채워 넣는 커밋이 계속 흐르고 있습니다 — 방향은 맞는데, 완주 시점은 아무도 약속하지 않았습니다.

오늘 기준 상태표

정리하면 2026년 7월 17일 현재 상태는 이렇습니다.

                          디코더 컴파일   기본 활성   수동 활성 방법
Chrome 151 (스테이블)          O            X       chrome://flags 의
                                                    enable-jxl-image-format
Firefox 152 (릴리스)           O            X       about:config 의
                                                    image.jxl.enabled
Firefox Nightly (154)          O            O       -
Safari 17+                     O            O       -

Intent to Ship (Chromium):     없음 (chromestatus 상태 "Proposed")
릴리스 기본 활성화 일정:        어느 엔진도 공표한 바 없음
Interop 2026:                  investigation effort (채점 대상 아님)

"3년 만에 처음으로 세 엔진 모두의 코드베이스에 JPEG XL 디코더가 존재한다"는 문장과 "여전히 웹 트래픽의 대부분에서 JPEG XL은 렌더링되지 않는다"는 문장이 동시에 참입니다. 이 두 문장을 같이 들고 있는 것이 지금 이 주제에 대한 정확한 이해입니다.

실무 판단 — 지금 무엇을 하고, 무엇을 하지 말아야 하나

지금 하지 말아야 할 것부터. 유저에게 나가는 웹 이미지 포맷을 JPEG XL로 전환하는 일입니다. Chrome 계열과 릴리스 Firefox에서 기본 미지원이므로, content negotiation 없이 .jxl을 내보내면 대부분의 사용자에게 깨진 이미지가 갑니다. WASM 폴리필로 우회하는 선택지도 있지만 — 앞의 회고 글 저자가 만든 폴리필은 제작자 표기 기준 gzip 후 약 540KB입니다 — 이미지 몇십 KB를 아끼자고 540KB 런타임을 얹는 것은 대부분의 웹 성능 시나리오에서 본말전도입니다. 폴리필이 값을 하는 곳은 JXL 원본을 이미 대량 보유한 특수한 뷰어류 정도입니다.

지금 해 둘 만한 것. 첫째, 이미지 파이프라인이 <picture>나 Accept 헤더 기반 포맷 분기를 이미 갖추고 있는지 점검하세요. WebP에서 AVIF로 넘어올 때 만들었던 그 구조가 그대로 JXL 수용 통로가 됩니다 — 포맷이 하나 더 늘어나는 것뿐입니다. 둘째, CDN이나 오리진 로그에서 Accept: image/jxl의 등장 비율을 관측 항목에 넣어 두세요. Safari와 플래그를 켠 사용자들이 이미 보내고 있고, 이 비율이 계단식으로 뛰는 날이 어떤 브라우저가 기본값을 바꾼 날입니다. 셋째, 판단 신호를 뉴스가 아니라 1차 소스에 걸어 두세요. 진짜 신호는 두 가지입니다 — blink-dev에 "Intent to Ship: JPEG XL"이 올라오는 것, 그리고 Firefox의 image.jxl.enabled 기본값이 Nightly 조건 없이 true로 바뀌는 커밋. 이 둘 중 하나가 일어나기 전까지는 전부 준비 운동입니다.

덧붙여, 이 사례에는 포맷과 무관한 교훈이 하나 있습니다. 2022년의 제거는 "품질이 나빠서"가 아니라 "유지보수 부담을 질 이유가 부족해서"였고, 2025년의 번복은 벤치마크가 아니라 그 부담의 구조를 바꾼 것(메모리 안전 공유 디코더 + 외부 기여 + 유지보수 약속)이 만들었습니다. 브라우저에 기능을 넣는 문제에서 기술 우위 논쟁은 생각보다 변수가 아니고, 유지보수 경제학이 상수입니다.

마치며

"JPEG XL이 돌아왔다"의 정확한 버전은 이렇습니다 — Chromium이 조건을 걸고 문을 열었고, 외부 기여자와 libjxl 팀의 Rust 디코더가 그 문으로 들어갔으며, Firefox는 같은 디코더를 한 발 먼저 싣기 시작했고, Safari는 애초에 떠난 적이 없다. 그러나 2026년 7월 현재 어떤 엔진도 릴리스 기본값을 바꾸지 않았고, 바꾸겠다는 일정도 없다.

그래서 지금 할 일은 전환이 아니라 관측입니다. 포맷 분기 구조를 정비해 두고, Accept 헤더를 지켜보고, Intent to Ship이라는 단 하나의 진짜 신호를 기다리는 것 — 그게 오늘 시점에서 JPEG XL에 대해 실무자가 취할 수 있는 가장 정직한 포지션입니다.

참고 자료

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

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.

References