一张图片，压缩效率能比 JPEG 高 30% 到 50%。
2026年10月6日，Chrome 官方宣布，Chrome 155 开始支持 JPEG XL 解码。
它还能无损压缩、内置 HDR、支持无损 JPEG 转码。
插一句，JPEG XL 的扩展名是 .jxl。
但这次更扎眼的，可能不止这个后缀。
Chrome 官方把图像解码器称为浏览器里最关键、也最容易被攻击的表面之一。为了这个格式，他们把解码器用 Rust 重新实现了一遍。
老实讲，图片格式更新听起来像前端小事。
一旦牵涉到内存安全、SIMD、性能、互操作，它就变成了浏览器底层的一次硬仗。
解码器这个入口，浏览器一点都不敢大意
图像解码器为什么重要？
因为它要直接处理来自网络、不可信的二进制结构，还运行在渲染进程里。
这条消息来自 Chrome for Developers 博客，作者包括 Luca Versari、Moritz Firsching 和 Philip Jägenstedt。
素材里说得很直白：历史上，用 C++ 这类内存不安全语言写成的解码器，容易出现越界读、堆溢出、释放后使用等漏洞。
Chrome 的安全模型依赖沙箱和纵深防御，也提到 rule of two。
但官方也承认，沙箱只是第二层防线。
所以他们的选择很直接：把风险从源头掐掉。
答案就是 jxl-rs，一个纯 Rust 实现的 JPEG XL 解码器。
Rust 进场，安全先拉满
个人觉得，这次最有看头的地方，是 Chrome 没有把 Rust 当宣传词。
他们把 Rust 放进了图像解码这个高风险位置。
Rust 的价值，也不只是听起来更安全。
官方给出的验证方式很硬：fuzzing、AI code review、多平台性能跟踪。
结果是，在整个实现历史中，没有发现内存安全 bug。
这句话值得划重点。
We verified the
jxl-rsimplementation with various state-of-the-art techniques, including fuzzing and AI review of the code, and have not found any memory safety bugs throughout the entire implementation history.
当然，0 个发现不等于绝对无漏洞。
但至少说明，Rust 在内存安全上的收益，已经被 Chrome 拿真实项目验证过一轮。
安全如果太慢，也很难变成默认选项
安全语言如果慢得明显，很难被浏览器这种性能怪兽采纳。
Chrome 也很坦白：内存安全很重要，但一个安全解码器如果速度和最好的非安全方案差不多，才是更显然的选择。
说白了，安全不能以明显卡顿为代价。
JPEG XL 这类现代编解码器，想吃满硬件性能，绕不开 SIMD。
为了安全使用 SIMD，Rust 需要稳定 target_feature_11 特性，让 SIMD 指令可以在不写 unsafe 的前提下使用。
然后，Chrome 团队又搭了一层 SIMD 抽象，叫 jxl_simd。
这个层受到 C++ Highway 库启发，而 Highway 最早就是给 libjxl 用的，libjxl 是 JPEG XL 的 C++ 参考实现。
这段挺有意思。
Rust 版解码器并没有和 C++ 生态一刀两断，反而站在原有性能积累上继续跑。
性能优化也延续了 libjxl 的经验，包括跨区域边界的通用处理流水线，尽量减少数据拷贝，把硬件性能挤出来。
Chrome 还专门做了 jxl-rs 性能仪表盘，在不同硬件平台跟踪 Rust 重实现的表现。
表面是新格式上车，暗线是开发者把它催进了 Chrome
很多人第一眼会把这件事理解成：Chrome 又支持了一个新图片格式。
往下看，会发现推动力并不只在技术侧。
Chrome 团队提到，决定上线 JPEG XL，来自持续开发者反馈。
渠道包括 bug、调查、Developer Signals Project，以及 Interop Project。
其中，JPEG XL 在 Interop 流程里是 2026 年的热门提案，之前几年也多次出现。
这点很关键。
一个图像格式能不能进浏览器，不只看压缩率，也要看开发者是不是真的需要。
Chrome 还参与了 Interop 2026 JPEG XL Investigation，目标是确保 JPEG XL 的各项功能在浏览器中有测试覆盖，并且这些测试能在 Chrome 通过。
换句话说，这次上车的背后，有标准、有测试、有开发者呼声。
它更像一次被需求推着走的结果。
现在该不该把 .jxl 放进图片管线
如果你的业务里有大量照片、高保真图、HDR 内容，或者你特别在意无损压缩和渐进解码，JPEG XL 值得进入测试清单。
Chrome 官方建议也很实在：AVIF 和 JPEG XL 都可以试，选最适合自己内容的结果。
他们预期 JPEG XL 最能打的场景，是高保真或无损压缩，尤其适合摄影图像，以及需要细粒度渐进解码的场景。
这里没有一个格式打天下。
AVIF 还在桌上，JPEG XL 也上桌了。
图片格式的格局，看起来更像多路线并行。
对开发者来说，.jxl 已经可以在 Chrome 155 开始的解码能力里试起来。
下一步，就是真实业务里的图片管线、兼容性测试、性能收益和 bug 反馈。
当压缩率、HDR、无损、安全和互操作被塞进同一张图片，Web 图片的竞争标准也变了。
你更在意少传几十 KB，还是更在意浏览器敢不敢放心解码？
【锐评】：Chrome 这次端上 JPEG XL，表面卷图片压缩，实际把解码器安全按进了 Rust 时代。
参考链接：
https://developer.chrome.com/blog/jpeg-xl-in-chrome