谷歌浏览器（Chrome）从155版本开始提供 JPEG XL（JPEG XL）图像格式的解码支持。该格式为新一代图像格式，为满足现代网页开发者和摄影师需求而设计，相比 JPEG 可提供30-50%更佳压缩，支持无损压缩、内置 HDR 及无损 JPEG 转码等。通常建议同时尝试 AVIF 与 JPEG XL 以获取最佳结果，JPEG XL 在高保真或无损压缩（尤其摄影图像或偏好精细渐进解码的情况）中最有帮助。

2026年10月6日，我们高兴地宣布，从 Chrome 155 开始，Chrome 将支持 JPEG XL（.jxl）图像格式的解码。JPEG XL 是新一代图像格式，满足现代网页开发者和摄影师的需求，比 JPEG 压缩效率高出 30-50%，支持无损压缩、内置 HDR、无损 JPEG 转码等。

我们通常建议同时尝试 AVIF 和 JPEG XL 以获得最佳效果，预计 JPEG XL 在高保真或无损压缩（尤其是照片图像，或需要精细渐进解码的场景）中最有帮助。

安全优先：用 Rust 重新实现解码器（jxl-rs）

图像解码器是浏览器中最关键且最易被攻击的表面之一，直接处理来自网络、复杂的不可信二进制结构。历史上，C++ 等内存不安全语言写的解码器常有越界读取、堆溢出和释放后使用等漏洞。我们的安全模型依赖沙箱和纵深防御，遵循 规则二，但沙箱只是次级防御。为从源头消除风险，我们集成了纯 Rust 实现的 JPEG XL 解码器 jxl-rs。

为速度设计，不牺牲安全

内存安全至关重要，但一个和最佳非安全方案差不多快的内存安全解码器，显然比牺牲性能的选择更合理。现代编解码器性能的关键在于充分利用现代设备的 SIMD 硬件。为此，Rust 稳定了 target_feature_11 特性，允许在不写 unsafe 代码的情况下使用 SIMD 指令。

下一步是构建受 C++ Highway 库（最初为 libjxl 开发）启发的 SIMD 抽象层 jxl_simd。这些工作让我们能写出不牺牲 SIMD 性能优化的多平台库，同时将不安全操作限制在极少数经过严格审查的位置。

jxl-rs 的优化建立在 libjxl 基础上，包括处理跨区边界步骤的通用流水线，并尽量减少数据拷贝以最大化硬件性能。我们在 jxl-rs 性能面板 上追踪不同硬件平台的表现。通过模糊测试和 AI 代码审查等多种先进技术验证，整个实现历史中未发现任何内存安全漏洞，再次印证了 Rust 带来的巨大提升。

开发者反馈与 Interop 项目

Chrome 团队重视来自 bug、调查、开发者信号项目 和 Interop 项目 等广泛渠道的反馈。我们发布 JPEG XL 的决定基于开发者持续一致的反馈与请求，这在 Interop 流程中最明显——它在 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 本身贡献良多）。

Chrome 重新支持 JPEG XL 的消息总体被视为好消息，讨论气氛以期待和「终于」为主；分歧集中在 JXL 与 AVIF 谁更值得押注、Safari 是否已取代 Chrome 成为新的瓶颈，以及生态兼容性的实际拖累有多大。

认为这是迟到但必要的一步

• Chrome 在移除多年后重新加入支持，此前正是最主流浏览器的缺席限制了 JXL 在网页上的采用（较多人）
• 现在主流浏览器加上主流操作系统基本都已支持，Firefox 也即将跟上（较多人）
• 引用： > 等这一天很久了，虽然我更希望最终只留一个格式，但至少 webp 可以就此退场了。（@revolvingthrow）

认为 Safari 已经变成新的拖后腿者

• 龟兔赛跑的比喻被翻了出来：libjxl 早就支持渐进式加载，Firefox 桌面版和 Chrome 都已启用，Safari 反而还没打开这个开关（较多人）
• 有人追问 Android Chrome 是否也开了，并指出 Safari 在 macOS 和 iOS 上既没有渐进渲染也没有动画支持，提醒这只是一个必要步骤而非终点（较多人）
• 引用： > 兔子睡着了，乌龟却跑到了前面，三年的棋钟现在翻面了。（@cyberrock）

认为 AVIF 仍是更稳妥的押注

• 在每像素 1 bit 及更低的码率区间，AVIF 依然更强，JXL 能否追上还不确定（较多人）
• 有实际迁移经验的人提到，AVIF 在极高压缩率下会出现不明显的画质流失，但几乎所有指标仍胜过 jpg 和 png；JXL 是否在压缩率和质量上明确胜出尚不清楚，因此暂时按兵不动（少数人）
• 引用： > 我几年前从 jpg、png 迁到 avif，回头看是对的；现在面对 JPEG XL，我还在观望。（@shevy-java）

认为真正的瓶颈是生态兼容，而不是格式优劣

• 新格式的兼容性危机反复上演：Telegram 对 webp 的处理方式依然古怪，macOS 跟进缓慢，很多看图软件永远不会更新（较多人）
• 有人提醒扩展名无法区分有损与无损，这对普通用户是额外的认知负担（少数人）
• 引用： > 每次新图片格式出现，我想到的都是应用之间那场兼容性灾难。（@kelseydh）

担心重演 JPEG2000 式的专利与许可困局

• 有评论直接发问，这是不是又一个 JPEG2000 那样的专利／许可噩梦（少数人）

认为 Google 的转向更可能是被动跟随而非被工程师说服

• 有人原本期待看到 Google 高层阻挠、工程师最终说服他们的内部博弈报道，但更可能的情况是工程师从未赢下这场辩论，只是等其他浏览器都支持后高层才放弃抵抗（少数人）

有价值的补充

• 有人整理了完整的历史脉络：Chrome 110 计划弃用、Chromium 正式移除、相关 issue 重新打开，以及那篇主张反对 JXL 的文章，可作为理解这次转向的上下文
• 有评论给出时间表视角，认为 2026 年可能成为 JPEG XL 之年，互操作性是关键节点
• 对终局格式的设想：无损、16 bit 色深、gzip/bzip2 级别的简单压缩，并去掉如今已过时的 PNG 逐行加载设计，真正昂贵的部分其实是元数据的无 hack 存储
• 有人看到示例图逐行加载时闪回到 256 色交错 GIF 缓慢下载的年代，说明渐进式呈现本身就有直观的说服力
• 一条 xkcd 927（「标准」）的引用代表了社区对格式林立的疲惫情绪