作者：Luca Versari、Moritz Firsching、Philip Jägenstedt
我们很高兴地宣布，Chrome 将从 Chrome 155 开始正式支持 JPEG XL（.jxl）图像格式的解码。JPEG XL 是一种新一代图像格式，旨在满足现代 web 开发者和摄影师的需求。它提供比 JPEG 高 30-50% 的压缩率、无损压缩、内置 HDR 支持、无损 JPEG 转码等特性。
一般来说，我们建议同时尝试 AVIF 和 JPEG XL 以获得最佳效果。我们预计 JPEG XL 最适用于高保真或无损压缩场景，尤其是摄影图像，或者偏好细粒度渐进式解码的情况。
在本文中，我们将分享为什么将 JPEG XL 引入 Chrome、我们如何使用 Rust 优先确保内存安全、使其快速运行的广泛性能优化工作，以及这段历程所揭示的开发者反馈与 web 标准生态系统的运作方式。
安全第一：用 Rust 重新实现解码器（jxl-rs）
图像解码器是任何现代 web 浏览器中最关键、最受攻击者关注的攻击面之一。它们直接处理来自网络的复杂且不受信任的二进制结构，并在渲染器进程中运行。从历史上看，用 C++ 等内存不安全语言编写的解码器容易出现越界读取、堆溢出和释放后使用（use-after-free）等漏洞。
我们的安全模型依赖沙箱和纵深防御，并以“二规则”（rule of two）为指导。然而，沙箱只是第二层防御。为了从源头消除这些安全风险，我们集成了 jxl-rs——JPEG XL 解码器的纯 Rust 实现。
为速度而设计，不牺牲安全性
内存安全至关重要，但如果一个内存安全的解码器在速度上接近最好的非内存安全替代方案，它显然是比在性能上做出重大妥协的方案更好的选择。
现代编解码器性能的一个基本要素是充分利用现代设备上可用的 SIMD 硬件。为了安全地做到这一点，必须先稳定 Rust 的 target_feature_11 特性，它允许在不使用 unsafe 代码的情况下使用 SIMD 指令。
下一步是构建一个 SIMD 抽象层（jxl_simd），其灵感来自 C++ 的 Highway 库（该库最初是为 libjxl——JPEG XL 的 C++ 参考实现——而开发的）。这些进展共同使得编写一个在 SIMD 性能优化上毫不妥协的多平台库成为可能，同时将不安全操作限制在少数经过严格审查的位置。
jxl-rs 的性能优化建立在 libjxl 的基础上，包括用于处理跨区域边界步骤的通用处理管线，同时最大限度地减少数据拷贝以最大化硬件性能。我们在 jxl-rs 性能看板上持续跟踪 Rust 重实现在不同硬件平台上的性能表现。
我们使用多种最先进的技术验证了 jxl-rs 实现，包括模糊测试（fuzzing）和 AI 代码审查，并且在整个实现历史中未发现任何内存安全漏洞，这再次验证了 Rust 为内存安全带来的巨大改进。
Chrome 团队会考虑来自多种渠道的 web 开发者反馈，例如 bug 报告、调查问卷、Developer Signals Project 和 Interop Project。我们决定在 Chrome 中支持 JPEG XL，正是基于 web 开发者持续一致的反馈和请求——这在 Interop 流程中最为明显，它是 2026 年及之前数年的热门提案。
为确保该格式在各浏览器之间可互操作，我们参与了 Interop 2026 JPEG XL Investigation，以确保 JPEG XL 的所有功能在浏览器中都有测试覆盖，并且这些测试能在 Chrome 中通过。
试用
随着 JPEG XL 正式登陆 Chrome，web 变得更快、更丰富、更安全。我们鼓励开发者、内容创作者和平台所有者开始在各自的工作流程中使用 .jxl 图像和动画。
试用一下，提交 bug，帮助我们继续为每个人构建更快、更安全的 web。
致谢
我们要感谢所有为 jxl-rs 或其在 Chrome 中的集成做出贡献的人，尤其感谢 Helmut Januschka 对 Chrome 集成和 jxl-rs 的重大贡献，以及 Martin Bruse、Zoltan Szabadka、Sami Boukortt 和 Wonwoo Choi 对 jxl-rs 本身的重大贡献。
除非另有说明，本页面内容采用 Creative Commons Attribution 4.0 License 许可，代码示例采用 Apache 2.0 License 许可。详情请参阅 Google Developers Site Policies。Java 是 Oracle 及/或其关联公司的注册商标。