編按：本文綜合整理自 Chrome for Developers 官方部落格、jxl-rs GitHub 儲存庫、Chromium issue 追蹤 以及 Hacker News 討論串，並加入 Siami 編輯部觀點與分析。
Chrome 團隊正式將 JPEG XL（檔名為 .jxl）的解碼功能，從 Chrome 155 開始列入預設支援。這距離 Chrome 當年悄悄移除 JXL 支援，已經過了好幾年——當年（2023 年）Chromium 曾因種種考量放棄這個格式，如今捲土重來，背後推手是整個團隊用 Rust 從零重寫的 jxl-rs 解碼器。
對網頁開發者與影像工作者來說，這是一個值得記下來的分水嶺：現代瀏覽器三大主力（Chrome、Firefox、Safari）現在都對新一代圖片格式具備一定程度的解碼能力，.jxl 從「孤兒格式」重新站穩腳步。
JPEG XL 是什麼？為什麼等了十年？
JPEG XL 是 ISO/IEC 18181 定義的下一代靜態影像格式，由 JPEG 委員會（前身是為了解 JPEG 的侷限而成立的工作小組）所制定，目的是為了徹底取代 1992 年問世的 JPEG 標準。它主打以下幾個特點：
- 壓縮率比 JPEG 好 30-50%：同樣視覺品質下，檔案大小大幅縮減。
- 支援無損壓縮：對於攝影、影像素材這種不容忍雜訊的工作流來說是剛需。
- 內建 HDR 支援：能處理高動態範圍的元數據，不需要另存 HDR 版本。
- 無損 JPEG 轉碼：現有的
.jpg檔案可以無失真地轉成.jxl，檔案還能再壓縮 20% 左右。 - 動畫支援：類似 GIF 的動畫能力，但用新一代編碼。
Chrome 團隊在公告中明說，他們對 AVIF 與 JPEG XL 兩者都推薦開發者嘗試。AVIF 在某些高壓縮比的場景表現出色，但 JPEG XL 在「高保真、無損、需要漸進解碼」的情境下尤其佔優——這也是它對專業影像工作者最有吸引力的地方。
對網頁前端而言，這不是「再學一個格式」這麼簡單，而是「少壓幾張圖，省頻寬、減少 CDN 費用」這種會直接反應在帳單上的事。
為什麼這件事重要：從「棄兒」到「Rust 復活」的故事
這次能夠成真，背後有一段值得展開的故事。Chrome 在 2023 年初的版本（Chrome 110 時代）就已經把 JPEG XL 從預設支援裡拿掉，當時的理由包含「生態系尚未到位」「維護成本過高」「AVIF 已經是更主流的選擇」等。
社群當時反彈不小——畢竟 JPEG XL 已經是個 ISO 標準，設計上也明顯優於 JPEG，卻被市占率最高的瀏覽器放生，等於是技術上寫好了、實務上卻不能用。
2024 年起，社群裡開始出現「如果用 Rust 重寫解碼器，能不能解決記憶體安全問題？」的討論。這個方向跟 Chrome 團隊整體的策略一致：他們在 V8、Skia 等子系統已經大量採用 Rust 來降低記憶體漏洞風險。jxl-rs 這個專案就在這樣的背景下誕生，並且最後被 Chrome 接受作為預設解碼器。
換句話說，這不只是一個「支援新格式」的小改動，而是瀏覽器開發方法論的轉向：
- 過去：解碼器幾乎都是 C++ 寫的，靠沙箱化與深度防禦補漏洞。
- 現在：直接把核心元件用 Rust 重寫，從源頭消除記憶體安全風險。
這個轉變的指標意義，比 JPEG XL 這個具體格式更重要。
技術細節：jxl-rs 怎麼做到又快又安全？
Chrome 公告詳細解釋了他們怎麼兼顧「記憶體安全」與「高效能」這兩件原本被認為是 trade-off 的事：
SIMD 抽象層（jxl_simd）
現代 codec 的效能，很大程度上取決於能否善用 CPU 的 SIMD 指令集（SSE、AVX、NEON 等）。但 SIMD 指令在 Rust 裡屬於 unsafe 區塊，寫不好就是 UB（未定義行為）。
jxl-rs 團隊做了一件聰明的事：他們先在 Rust 裡穩定了 target_feature_11 這個 feature，讓 SIMD 指令可以在「沒有 unsafe 程式碼的情況下」被使用。然後他們參考了 Google 自家 C++ 的 Highway 函式庫（Highway 本身就是 libjxl C++ 參考實作的基礎之一），建立了一個 Rust 版本的 SIMD 抽象層 jxl_simd。
結果就是：開發者可以在 Rust 裡享受 SIMD 的效能，卻不需要直接面對 unsafe 的危險。unsafe 被縮限在少數經過嚴格審查的位置——這正是 Rust 生態系對「效能」與「安全」這兩難的最佳解方之一。
持續 fuzzing 與 AI code review
Chrome 團隊還透露，他們用「最先進的 fuzzing 技術」加上「AI 程式碼審查」對 jxl-rs 進行驗證——結果是「整個開發過程中沒有找到任何記憶體安全漏洞」。
這個成果對 Rust 的「記憶體安全保證」是一個很有力的佐證。當然，現實中 Rust 的 unsafe 區塊仍然可能出問題，但當 unsafe 被縮限到很小、很明確的範圍時，傳統 C++ 程式庫那種「打地鼠」式修漏洞的循環，就有機會被打破。
🚨 數據解讀與質疑
1. 解碼 ≠ 編碼
這次的公告只提到「解碼（decoding）」支援，並沒有提到 Chrome 155 會內建 JPEG XL 的**編碼（encoding）**能力。對使用者來說差別不大（瀏覽器本來就只需要解碼），但對開發者來說，這意味著「你想讓使用者上傳 JXL 圖片」這個使用情境，在前端還是得靠 canvas.toBlob('image/jxl') 或 server-side 工具來編碼。
這個不對稱的支援，可能會讓 JXL 在「瀏覽器原生支援」這件事上，落地速度比 AVIF 慢——畢竟 AVIF 是 Chrome 從編碼到解碼都有完整支援。
2. 與 AVIF 的競爭不會消失
Chrome 自己在公告裡也承認：「選項」（choice）比「統一」更重要。也就是說，AVIF 跟 JPEG XL 會繼續並存，短期內不會有「官方欽定格式」這種事。
對生態系來說，這是好事——多一個選項總比少一個好。但對開發者來說，決策成本變高了：你得根據具體場景（高保真 vs 高壓縮、靜態 vs 動畫、相容性 vs 檔案大小）來選格式。
3. WebP 的「棺材釘」是否真的釘得下去？
HN 討論中有人提到：「這至少是 WebP 棺材的最後一根釘子，WebP 似乎除了煩人之外沒什麼貢獻。」這個觀察有道理——WebP 雖然比 JPEG 好，但既沒有 JPEG XL 的「無損 JPEG 轉碼」能力，也沒有 AVIF 的「AV1 編碼壓縮比」加持，定位尷尬。
不過實務上，WebP 仍然會繼續存在很長一段時間：它是早期被設計為 JPEG 透明替代品的格式，已經深植於許多系統的圖片 pipeline（macOS Finder、Line 與 Telegram 的貼圖系統等），不可能一夜消失。比較務實的看法是：WebP 會慢慢變成「JPEG 的透明版」這種特定用途，而不是「新一代主流格式」。
4. 跨瀏覽器時程表
- Safari：已經支援 JPEG XL 一段時間了（iOS 27 開始，Photos app 也能直接開 JXL）。
- Chrome 155：這次公告。
- Firefox：根據 HN 討論，10 月底之前會在穩定版加入。
也就是說，到 2026 年 10 月底，三大瀏覽器都會對 JPEG XL 具備一定的解碼支援——這正是 JPEG XL 多年來最渴望達到的「跨瀏覽器覆蓋率」門檻。對開發者來說，這代表 .jxl 終於可以正式列入生產環境的「可用格式」清單。
社群迴響：Hacker News 上大家怎麼看？
這篇公告在 Hacker News 上拿下了 439 分、284 則回應（截至本文撰寫時），是近期相當熱門的技術話題。以下摘錄幾則代表性的看法：
jug（184 讚）：Firefox 也很快會在穩定版加入 JPEG XL，10 月就會從「只有 Safari 支援」變成「多數瀏覽器都支援」，這個月很熱鬧。
xx_ns（92 讚）：很高興看到 Chrome 把 JXL 加回來。Chrome 之前曾經拒絕支援，這讓 JXL 在 web 上很難普及。
kelseydh（38 讚）：每次新圖片格式出來，就會想到 app 間相容性問題。Telegram 對 WebP 還是很怪，把它當成貼圖；macOS 更新支援新格式也要時間；圖片檢視 app 更慢，很多 app 從未更新支援新格式。
swiftcoder（整理時間線）：回顧一下——Chrome 110 打算棄用 JXL → Chromium 正式移除 JXL → Chromium JXL issue 重開 → 最終復活。
一個有趣的觀察是：HN 社群對這則公告幾乎沒有負面聲音。相較於過去 Chrome 移除 JXL 時的爭議，這次的「復活」被普遍視為正面消息。這也呼應了 2026 年整個 web 生態系對「記憶體安全 + 高效能」這條路線的共識。
怎麼試用？
Chrome 155 之後，使用者只要把瀏覽器升級到最新版本，就可以直接在網頁上看到 .jxl 圖片（Chrome 也支援 .jxl 動畫）。對開發者來說：
- 準備素材：用
cjxl工具（libjxl 官方 CLI）把現有 PNG、JPEG 轉成 JXL。可以選擇無損轉檔（從 JPEG 來），通常能再省 20% 容量。 - 設定
<picture>標籤：用<source type="image/jxl" srcset="...">提供 JXL 版本，再用 fallback 給不支援的瀏覽器 JPEG/AVIF 版本。 - CDN 配置：主流 CDN 都會根據 Accept header 自動選格式，但如果你的 CDN 不支援，可能需要手動判斷。
- 追蹤 bug：發現問題就到 Chromium bug tracker 開 issue——Chrome 團隊在公告中明確鼓勵開發者回報。
結論：十年磨一劍的圖片格式，終於迎來它的時刻
JPEG XL 的故事，是一個「技術上早就準備好，卻因為種種生態系因素而被推遲」的典型案例。從 2017 年的標準發布，到 2020 年的瀏覽器支援嘗試，再到 2023 年的 Chrome 棄用，最後到 2026 年的 Rust 重寫復活，整整走了將近十年。
但現在，**Chrome 155 + Firefox 156 + Safari 27（iOS 27 起）**這個組合，標誌著 JPEG XL 正式進入「生產可用」的階段。對 web 開發者來說，這是 2026 年下半年最值得關注的圖片格式新聞；對整個 web 生態系來說，這也是 Rust 在大型開源專案中「從源頭解決記憶體安全問題」路線的一個重要里程碑。
一個
.jxl檔案背後的故事，比大多數人想像的更曲折。
延伸閱讀：
網友熱門留言 (5)