Chrome 155 开始支持 JPEG XL 图片格式解码

跳至主要内容

发布时间：2026 年 10 月 6 日

我们很高兴地宣布，从 Chrome 155 开始，Chrome 将支持对 JPEG XL (.jxl) 图片格式进行解码。JPEG XL 是一种新一代图片格式，旨在满足现代 Web 开发者和摄影师的需求。与 JPEG 相比，它可提供 30-50% 的压缩率，支持无损压缩、内置 HDR 支持、无损 JPEG 转码等。

一般来说，我们建议您同时尝试 AVIF 和 JPEG XL，以获得最佳效果。 我们预计，JPEG XL 最适合用于高保真或无损压缩，尤其是摄影图像，或者需要细粒度渐进式解码的情况。

在这篇博文中，我们将分享以下内容：我们为何将 JPEG XL 引入 Chrome、如何使用 Rust 首先确保内存安全、为实现快速运行而开展的广泛性能工作，以及这一历程如何让我们了解开发者反馈和 Web 标准生态系统。

安全第一：使用 Rust 重新实现解码器 (jxl-rs)

图片解码器是任何现代网络浏览器中最关键且最容易受到定向攻击的攻击面之一。它们直接从网络处理复杂且不受信任的二进制结构，并在渲染器进程中运行。从历史上看，使用 C++ 等非内存安全型语言编写的解码器容易出现越界读取、堆溢出和释放后使用 bug 等漏洞。

我们的安全模型依赖于沙盒和纵深防御，并遵循双重规则。 不过，沙盒是次要的防御层。为了从源头上消除这些安全风险，我们集成了 jxl-rs，这是 JPEG XL 解码器的纯 Rust 实现。

为速度而生，安全绝无妥协

内存安全至关重要，但与最佳的非内存安全替代方案相比，速度大致相当的内存安全解码器比性能明显下降的解码器更具吸引力。

现代编解码器的性能在很大程度上取决于是否充分利用了现代设备上可用的 SIMD 硬件。为了安全地实现这一点，target_feature_11 Rust 功能必须稳定，这样才能使用 SIMD 指令，而无需 unsafe 代码。

下一步是构建一个 SIMD 抽象层 (jxl_simd)，其灵感来自 C++ Highway 库（该库本身最初是为 libjxl（JPEG XL 的 C++ 参考实现）开发的）。这些发展共同促成了多平台库的编写，该库在不影响 SIMD 性能优化的同时，将不安全的操作限制在少数经过高度审查的位置。

jxl-rs 中的性能优化以 libjxl 中的性能优化为基础。这包括一个用于跨区域边界的步骤的通用处理流水线，同时最大限度地减少数据复制，以最大限度地提高硬件性能。我们一直在 jxl-rs 性能信息中心上跟踪 Rust 重新实现的性能，包括在不同硬件平台上的性能。

我们使用各种前沿技术（包括模糊测试和 AI 代码审核）验证了 jxl-rs 实现，在整个实现历史记录中未发现任何内存安全 bug，这进一步验证了 Rust 在内存安全方面带来的巨大改进。

开发者反馈和互操作性项目

Chrome 团队会通过各种渠道（例如 bug 报告、调查问卷、Developer Signals 项目和 Interop 项目）收集 Web 开发者的反馈。我们决定发布 JPEG XL 是基于 Web 开发者的持续反馈和要求，这在 Interop 流程中最为明显，该流程中 JPEG XL 在 2026 年及之前几年都是热门提案。

为确保该格式在浏览器之间具有互操作性，我们参与了 Interop 2026 JPEG XL 调查，以确保浏览器中对 JPEG XL 的所有功能都有测试覆盖，并且这些测试在 Chrome 中通过。

试试看

随着 JPEG XL 正式登陆 Chrome，网络变得更快、更丰富、更安全。我们鼓励开发者、内容创作者和平台所有者开始在其流水线中使用 .jxl 图片和动画。

欢迎试用该版本、提交 bug，并帮助我们继续为所有人打造更快速、更安全的网络。

致谢

我们要感谢所有为 jxl-rs 或其在 Chrome 中的集成做出贡献的人，尤其是 Helmut Januschka，他为 Chrome 集成和 jxl-rs 做出了重大贡献；还要感谢 Martin Bruse、Zoltan Szabadka、Sami Boukortt 和 Wonwoo Choi，他们为 jxl-rs 本身做出了重大贡献。

如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。

最后更新时间 (UTC)：2026-10-06。