Chrome 155 預設支援 JPEG XL，解碼器改用 Rust 的 jxl-rs
Chrome for Developers · 2026-10-06
Chrome 不再把 .jxl 圖片當成無法解碼的檔案：從 Chrome 155 起，瀏覽器預設就能解碼 JPEG XL，而且解碼器不是 C++ 的 libjxl，而是純 Rust 寫成的 jxl-rs。官方文章發表於 2026-10-06，Hacker News 上同日有 463 分的討論。
背景：為什麼圖片解碼器是安全重災區
圖片解碼器要處理不受信任的位元組，用 C++ 實作時，緩衝區溢位與 use-after-free 是常見的漏洞類型。Chrome 官方文章把記憶體安全列為這次實作的首要考量，並說明做法符合 Chrome 的「Rule of Two」：沙箱只當第二道防線，先從源頭避免漏洞。
所以這次不是把既有的 C++ 解碼器接進來，而是採用 jxl-rs。官方文章與該專案 README 都稱它是純 Rust 的 JPEG XL 解碼器，README 並說明 Chrome/Chromium 與 Firefox 都在使用。
核心改動：安全與速度怎麼兼顧
Rust 要做 SIMD 通常得寫 unsafe。Chrome 團隊的做法是使用 Rust 的 target_feature_11 特性，讓 SIMD 程式不必靠 unsafe；另外建了 jxl_simd，這層抽象的設計靈感來自 Google 的 Highway 函式庫（Highway 原本為 C++ 參考實作而生）。
- SIMD：
target_feature_11加jxl_simd，避免為了效能犧牲記憶體安全。 - 管線：沿用 libjxl 的最佳化手法，包括減少資料複製的通用處理管線。
- unsafe 政策：jxl-rs README 寫明絕大部分程式是 safe Rust，必要的
unsafe需有安全註解，並由 Unsafe Rust 專家（非作者）審查。
效能方面，官方只提供 jxl-rs 效能儀表板；README 的說法是效能「接近（有時超過）」C++ 參考實作，且漸進式渲染支援更好、記憶體需求更低。文章未公布具體的解碼耗時或記憶體數字。
為什麼值得出貨：格式本身的賣點
官方列出的特性是比 JPEG 好 30-50% 的壓縮率、無損壓縮、內建 HDR、無損 JPEG 轉碼與漸進式解碼。其中無損 JPEG 轉碼對既有圖庫最實際：舊的 JPEG 檔可以轉成 JXL 縮小體積，而不是重新壓縮造成二次失真。
這個決定也參考了 Interop Project：JPEG XL 是 2026 年的熱門提案，Chrome 團隊參與了「Interop 2026 JPEG XL Investigation」，目的是讓跨瀏覽器有共同的測試覆蓋。文章建議同時試 AVIF 與 JPEG XL 取最佳結果，並指出 JXL 最適合高保真或無損的攝影類圖片。
影響範圍
對誰有影響，要分幾種角色看。文章沒有說明 Accept header 協商或 <picture> 寫法，以下為標準 HTML 的既有機制，並非 Chrome 文章內容。
| 角色 | 要檢查的事 |
|---|---|
| 圖片 CDN / 圖片服務 | 是否依 Accept 回 image/jxl；快取 key 是否已把 Accept 納入，否則 JXL 可能被送給不支援的瀏覽器 |
| 前端頁面 | 用 <picture> 把 JXL 放在 AVIF、JPEG 之前，其他瀏覽器自動往後 fallback |
| 用 feature detection 的程式 | 不要用 UA 判斷，改用實際解碼測試 |
| 資安與維運 | 文章說明新增的是 Rust 解碼器，沒有再引入 C++ 解碼面 |
<picture>
<source srcset="photo.jxl" type="image/jxl">
<source srcset="photo.avif" type="image/avif">
<img src="photo.jpg" alt="">
</picture>要測試的人，可以直接拿 .jxl 圖片在 Chrome 155 驗證；遇到問題，官方開了 Chromium 問題回報入口。至於其他平台（如 Android、WebView）的釋出時程，官方文章未說明。