图像格式的迭代向来缓慢：JPEG 诞生于 1992 年，PNG 在 1996 年定型，此后近三十年里，浏览器处理照片的主力格式没有发生过根本变化。WebP 在 2010 年代完成了第一次替换，AVIF 在 2021 年进入 Firefox 和 Chrome，而 JPEG XL 的命运则走出了一条罕见的 U 型曲线：2022 年 10 月被 Google 从 Chromium 中移除，理由是"生态系统兴趣不足"；2025 年 11 月，Chrome 架构技术负责人公开表示"欢迎为 Chromium 集成高性能、内存安全的 JPEG XL 解码器"；2026 年 8 月，Mozilla 发文确认 Firefox 157 将默认启用 JPEG XL；2026 年 10 月 6 日，Chrome 官方博客宣布解码支持随 Chrome 155 正式上线。四年时间，一个格式从被清除到成为三大浏览器共同支持的标准能力，这背后的工程决策与技术细节值得展开。
发生了什么
Chrome 155（2026 年 10 月 6 日起进入稳定通道）在 Blink 引擎中默认启用 JPEG XL（.jxl）图像的解码，页面可以直接通过 、CSS 背景或 元素加载 image/jxl 类型的图片。这次上线的是解码能力：浏览器能显示 JPEG XL 图像，但 Chrome 官方博客同时说明，对大多数场景他们仍建议开发者同时提供 AVIF 版本，两者各自适配不同的内容类型。
JPEG XL 相对 JPEG 的核心指标是压缩率：同等视觉质量下文件体积小 30% 到 50%。它还带了几项 JPEG 从未具备的能力：无损压缩模式、HDR（高动态范围）与广色域支持、动画序列，以及一项在工程上很特别的设计——无损 JPEG 转码。所谓无损 JPEG 转码，是指把现有 JPEG 文件直接转成 JPEG XL 格式而完全不重新编码像素，转码后的 .jxl 文件比原 JPEG 还小约 20%，并且随时可以无损还原回原始 JPEG。对存量图片库来说，这意味着迁移不需要面对"重新压缩导致画质损失"的取舍。
Firefox 方向的进展同步推进。Mozilla 在 2026 年 8 月发布的 Intent to Ship 中确认，JPEG XL 将在 Firefox 157 默认启用；Safari 则早在 2023 年就已支持该格式。到 2026 年底，JPEG XL 将成为三大浏览器引擎共同支持的图像格式。标准化方面，JPEG XL 于 2022 年定为 ISO/IEC 18181 标准，并被 PDF 2.0 相关工作指定为 HDR 内容的首选嵌入格式。
被移除与回归的原因
2022 年的移除决定在当时引发过大量讨论，Chrome 团队给出的理由是"生态系统兴趣不足"，即网站实际使用率低、工具链支持有限。反对者的观点指向另一个方向：网站不用 JPEG XL 的主要原因恰恰是市场份额最高的浏览器不支持它，这是一个自我实现的死循环。
打破循环的变量在 2023 到 2025 年间陆续出现。Safari 率先实现了 JPEG XL，证明了格式可以在生产级浏览器中落地；Mozilla 更新立场，表示只要有一个用内存安全语言编写的解码器就愿意支持；JPEG XL 被指定为 PDF 中 HDR 图像的首选格式，给了它浏览器之外的应用场景；Interop Project（跨浏览器厂商共同确定年度优先实现特性的协作机制）连续多年把 JPEG XL 列为高票提案，开发者需求有了正式的表达渠道。2025 年 11 月 Chrome 架构技术负责人的表态，等于正式撤销了 2022 年的关闭决定。
用 Rust 重写解码器：安全与性能的平衡
这次回归工程价值最高的部分，是 Chrome 没有直接复用现成的 C++ 参考实现 libjxl，而是集成了一个用纯 Rust 编写的解码器 jxl-rs。这个决策的背景是浏览器安全模型中的一个基本事实：图像解码器是现代浏览器最常被攻击的组件之一。解码器直接处理来自网络的、不受信任的二进制数据，运行在渲染进程内部，历史上用 C++ 编写的解码器反复出现过越界读取、堆溢出、释放后使用这类内存安全漏洞。
Chrome 的安全体系依赖沙箱和纵深防御，但官方博客明确表示沙箱只是第二道防线，要在源头消除这类风险，最好的办法是用内存安全的语言重写解码器。Mozilla 在 2021 年的立场更激进：当时 Firefox 曾在 flag 后面实验性支持过 JPEG XL，但面对十万行多线程 C++ 代码带来的攻击面，Mozilla 直接向 Google Research 的 JPEG XL 团队提出条件，用 Rust 写一个安全、高性能、紧凑且兼容的解码器，我们就发布它。jxl-rs 就是这个条件的产物，如今同时成为 Chrome 和 Firefox 的解码核心。
内存安全通常被质疑的点是性能损失，而 jxl-rs 的工作展示了两者可以兼得。现代编解码器的性能高度依赖 SIMD（单指令多数据流）指令集，要在 Rust 中安全地使用 SIMD，依赖 target_feature_11 特性的稳定化，它允许在不写 unsafe 代码的前提下调用 SIMD 指令。在此基础上，团队构建了独立的 SIMD 抽象层 jxl_simd，设计参考了 C++ 的 Highway 库（Highway 最初就是为 libjxl 开发的）。整个解码库的 unsafe 代码被限制在少量经过严格审查的位置，每一处都要求附带详尽的安全论证注释，并由非作者本人的 unsafe Rust 专家复审。据官方博客披露，jxl-rs 经过模糊测试和 AI 代码审查等多种手段验证，整个实现历史上未发现任何内存安全漏洞。
性能数据的对账
性能优化的路径也有迹可循。Chromium 集成的贡献者 Helmut Januschka 公开过集成过程中的解码耗时数据：一张 2048×2560 的测试图（bike），jxl-rs 早期版本解码耗时 265 毫秒，经优化后降到 198 毫秒，同期 C++ 参考实现 libjxl 为 170 毫秒；一张 4064×2704 的渐进式测试图从 694 毫秒优化到 560 毫秒（libjxl 450 毫秒）；一张 1024×1024 的混合模式测试图从 115 毫秒到 85 毫秒（libjxl 266 毫秒）。可以看出的趋势是：通用场景下 Rust 实现与 C++ 的差距已经收窄到百分数十以内，部分场景反超，这与 jxl-rs 官方仓库"性能与 C++ 参考实现相当、部分场景超越"的描述一致。
支撑这些数字的是一系列具体优化：SIMD 化的查表操作、F32 到 U8/U16 的转换、色度上采样、YCbCr 到 RGB 的色彩空间转换、2 倍 4 倍 8 倍的上采样、噪声卷积；非 SIMD 侧则有默认量化表缓存、系数自然序缓存、样条渲染中的余弦预计算、模块化树的扁平化处理等。这些优化大多来自集成过程中社区提交的 PR（编号 #524 到 #600 区间），Chrome 侧的集成则通过四个已合并的 CL 完成：将 jxl-rs 加入 third_party（CL 7201443）、添加基础设施与构建开关（CL 7320482）、接入 jxl-rs 的图像解码器（CL 7319379）、接线到 Blink 渲染管线（CL 7184969）。早期基于 libjxl 的 C++ 集成方案（CL 7170439）被放弃。
一个细节是渐进式解码。JPEG XL 的码流设计允许图像在只下载了前几个百分点字节时就渲染出一个可辨认的版本，随数据到达逐步精化。Mozilla 在 Mozilla Hacks 的文章中给出的演示是：一张完整体积 135 KB 的图像，只下载几 KB 时就已经能判断出画面主体。AVIF 的渐进式支持目前仍很基础，这是大图场景下选择 JPEG XL 的核心理由之一。
JPEG XL 与 AVIF 怎么选
两大现代格式并存，开发者需要的是选型依据而非替代关系。Mozilla 给出的分野相当清晰：JPEG XL 强在无损图像、渐进式渲染和无损 JPEG 转码；AVIF 强在网页质量的有损压缩，尤其擅长锐利边缘与平坦色块混合的内容（截图、图表、UI 界面）。
具体数据支持这个判断。Mozilla Hacks 的对比测试中，一张网页质量（SSIMULACRA 2 得分 78，属高质量）的截图，AVIF 压到 11.6 KB，JPEG XL 需要 23.8 KB；但在无损模式下同一张图，AVIF 是 164 KB，JPEG XL 只要 92 KB，比 AVIF 小 44%，也比无损 WebP（96 KB）更小。另一张照片类图像在高质量（SSIMULACRA 2 得分 80）下，AVIF 为 227 KB、JPEG XL 为 264 KB，AVIF 略胜；无损时 AVIF 1.76 MB、JPEG XL 1.45 MB，JPEG XL 胜出。SSIMULACRA 2 是 JPEG XL 团队开发的感知质量评分，分数越高代表与原图越接近。
选型建议可以归纳为三条。第一，照片类网站（摄影、电商商品图、图库）如果存量是海量 JPEG，JPEG XL 的无损转码路径几乎是量身定制：转码即得约 20% 的体积收益，画质零损失，且保留回退能力。第二，截图、图标、UI 素材为主的站点，AVIF 仍是更小的选择，继续用 AVIF 或已有的 WebP 即可。第三，大尺寸高分辨率图像（地图切片、艺术品数字化、印刷素材）应优先考虑 JPEG XL，渐进式渲染让用户在完整下载前就能看到图像轮廓，这类场景下 AVIF 的体验差距明显。
Chrome 官方博客给出的通用建议是两条腿都试：对同一批代表性图片分别用 AVIF 和 JPEG XL 压缩，在目标质量档位下比较实际体积，用数据而不是经验做决定。对于还没有原生支持的浏览器，社区提供了 jxl-rs-polyfill（WASM 实现，gzip 后约 540 KB），可以按需覆盖 、CSS 背景和 场景。
对图片密集型业务的实际影响
Chrome 155 与 Firefox 157 先后默认启用后，`` 元素的类型判断可以让浏览器在 JPEG XL 与 AVIF 之间自动选择，老浏览器继续回退到 WebP 或 JPEG。工具链层面，libjxl 提供的 cjxl/djxl 命令行工具已支持批量转码，cjxl input.jpg output.jxl 一条命令即可完成无损 JPEG 转码；Rust 生态的 jxl crate 也已发布到 crates.io，并提供了与通用图像库 image 的集成接口。
存量图片资产的处理策略在这次格式落地后有了新选项。过去网站迁移图像格式只有"重新编码换体积"一条路，JPEG XL 的转码模式把这件事变成了可逆操作：先无损转码拿到即时收益，浏览器支持面扩大后用户自动受益，任何时点都可以无损转回。对于图片存储量以 TB 计的平台，20% 的无损缩减直接对应存储与带宽成本的下降，而没有画质与兼容性风险。HDR 内容生态（相册、显示屏、PDF 文档）则获得了浏览器侧的显示通路，这在 JPEG 与 WebP 上是不存在的选项。
Firefox 157 预计在 2026 年 9 月底至 10 月进入稳定通道，届时三大引擎的支持将全部到位。图像格式的下一次更替通常以十年计，JPEG XL 从被移除到全面回归的过程说明，格式竞争的决定因素不只是压缩率数字，还包括安全工程（能否用内存安全语言实现）、标准化进展（PDF、HDR 等浏览器之外的场景）和跨厂商协作机制（Interop Project）这些更慢的变量。