前言
Chrome 從 155 版開始支援 JPEG XL（.jxl）解碼，用的是純 Rust 重寫的 jxl-rs。官方部落格在 2026 年 10 月 6 日公布，HN 上 4 小時內衝到 310 分、176 則留言。
這篇把官方原文翻譯和 HN 網友反應整理放在一起，上方互動圖表是完整懶人包。
官方原文翻譯
原文：https://developer.chrome.com/blog/jpeg-xl-in-chrome
作者：盧卡·維爾薩里（Luca Versari）、莫里茨·菲爾興（Moritz Firsching）、菲利普·耶根施泰特（Philip Jägenstedt）
發表日期：2026 年 10 月 6 日
我們很高興宣布，Chrome 將從 155 版開始支援 JPEG XL（.jxl）圖像格式的解碼。JPEG XL 是為滿足現代網頁開發者與攝影師需求而設計的次世代圖像格式。相較於 JPEG，它提供 30–50% 更高的壓縮率，並支援無損壓縮、內建 HDR、無損 JPEG 轉碼等功能。
一般來說，我們建議同時嘗試 AVIF 與 JPEG XL，以獲得最佳結果。我們預期 JPEG XL 在高保真或無損壓縮場景最有幫助，特別是攝影圖像，或需要精細漸進式解碼的場景。
安全優先：用 Rust 重寫解碼器（`jxl-rs`）
圖像解碼器是現代瀏覽器中最關鍵、也最常被攻擊的介面之一。它們直接處理來自網路、結構複雜且不可信任的二進位資料，並在渲染程序內執行。歷史上，以 C++ 這類記憶體不安全的語言撰寫的解碼器，容易出現越界讀取、堆積溢位、使用後釋放等漏洞。
我們的安全模型依賴沙箱與縱深防禦，並以「二者法則」為指導。但沙箱只是第二層防線。為了從源頭消除這類安全風險，我們整合了 jxl-rs，也就是以純 Rust 實作的 JPEG XL 解碼器。
為速度而設計，不犧牲安全
記憶體安全至關重要，但一個速度與最佳非記憶體安全方案相當的記憶體安全解碼器，顯然比一個要大幅犧牲效能的方案更容易被接受。
現代編解碼器效能的根本之一，是充分利用現代裝置上的 SIMD 硬體。要安全地做到這一點，必須先穩定 Rust 的 target_feature_11 特性，讓開發者無需撰寫 unsafe 程式碼就能使用 SIMD 指令。
下一步是打造 SIMD 抽象層（jxl_simd），靈感來自 C++ 的 Highway 函式庫（該函式庫最初正是為 JPEG XL 的 C++ 參考實作 libjxl 而開發）。這兩項進展加在一起，讓我們能寫出跨平台函式庫，在不犧牲 SIMD 效能優化的同時，把不安全操作限制在少數經過嚴格審查的位置。
jxl-rs 的效能優化建立在 libjxl 的基礎上，包括跨區域邊界步驟的通用處理管線，同時盡量減少資料複製以發揮硬體效能。我們一直在效能儀表板上追蹤 Rust 重寫版本在不同硬體平台上的表現。
我們以多種頂尖技術驗證 jxl-rs 實作，包括模糊測試與 AI 程式碼審查，在整個實作歷程中都沒有發現任何記憶體安全錯誤，再次驗證了 Rust 在記憶體安全上帶來的巨大進步。
開發者回饋與 Interop 專案
Chrome 團隊透過多種管道蒐集網頁開發者的回饋，例如錯誤回報、問卷、Developer Signals 專案與 Interop 專案。我們決定推出 JPEG XL，是基於開發者持續一致的回饋與請求，最明顯的是在 Interop 流程中，它在 2026 年以及此前數年都是熱門提案。
為確保該格式在各瀏覽器間可互通，我們參與了 Interop 2026 JPEG XL 調查，確保瀏覽器對 JPEG XL 所有功能都有測試覆蓋，且這些測試都能在 Chrome 中通過。
動手試試
隨著 JPEG XL 正式登陸 Chrome，網頁將變得更快、更豐富、更安全。我們鼓勵開發者、內容創作者與平台方開始在工作流程中使用 .jxl 圖像與動畫。
致謝
感謝所有為 jxl-rs 或其 Chrome 整合做出貢獻的人，特別是赫爾穆特·亞努施卡（Helmut Januschka）對 Chrome 整合與 jxl-rs 的大量貢獻，以及馬丁·布魯塞（Martin Bruse）、佐爾坦·薩巴德卡（Zoltan Szabadka）、薩米·布庫爾特（Sami Boukortt）與崔元佑（Wonwoo Choi）對 jxl-rs 本身的大量貢獻。
HN 網友反應整理
來源：https://news.ycombinator.com/item?id=49991227（310 分、176 則留言）
最大串：砍掉又加回來，Google 在想什麼
核心情緒是「奇蹟、終於留下來了」，但對動機眾說紛紜。有人認為是 Google 加入 Alliance for Open Media 後想挺 AVIF，也有人認為單純是 C 解碼器安全成本太高，現在有了 Rust 版才回頭。轉折點可能是 PDF 協會選 JXL 當下一代圖像格式，加上 Apple 早在 2023 年就系統層支援，Chrome 不跟不行。
安全與 jxl-rs
當年官方給的理由沒提安全，談安全的是 Firefox。但這次用 Rust 重寫確實緩解了疑慮：寫 Rust 版的大致就是當年寫 libjxl 的同一批人，效能儀表板顯示幾乎所有測試都比 C++ 版快。
JXL vs AVIF vs WebP
AVIF 在極低位元率省流量佔優，JXL 在高畫質照片存檔和無損壓縮佔優，無損 JPEG 轉碼是獨門絕招。攝影師抱怨 AVIF 會把微單照片修成廉價感，亮部是被重繪過的。WebP 則被不少人認為可以進棺材了。
又多一個打不開的格式
最多人共鳴的痛點：下載的 WebP 圖其他 App 打不開。擔心 JXL 重演孤島期。反方認為 JXL 在瀏覽器之外的採用熱情遠勝當年 WebP，iOS 與 macOS 新版 Photos、Quick Look、縮圖都已正常。
瀏覽器該內建，還是丟給 OS
一派主張交給 OS 共用函式庫（Amiga DataTypes、Windows WIC、macOS CGImage），一派認為交給 OS 等於把命運交給別人，靜態連結一次搞定。串中還歪樓到 Electron 體積和 dd 指令。
生態覆蓋
Firefox 158 預設開啟後，10 月內就從只有 Safari 變成多數覆蓋。Safari 目前還缺漸進渲染和動畫。HDR 強制亮瞎眼、副檔名看不出失真或無損、規格書要收費等雜項也被點名。
小結
技術上 JXL 幾乎沒短板，真正的變數是生態：手機拍攝端、CDN 轉檔、桌面軟體何時跟上。這次 Chrome 回歸補上最大缺口，10 月是關鍵月份。