最近，Google 已在 Chromium 引擎中重新加入对 JPEG XL 图像格式的原生支持，而且此次采用的是一个基于 Rust 开发的全新解码器——jxl-rs。简单来说，这次回归的核心目标非常明确：在保证内存安全的同时，也满足日益严格的安全合规与工程维护要求。

目前相关代码已经完成集成，但普通用户暂时仍需手动前往 chrome://flags 页面启用 #enable-jxl-image-format 这一实验性开关。自从 Chrome 110 在 2022 年低调移除 JPEG XL 支持后，这也是该格式首次重新回归 Chrome 正式渠道。至于其他主流浏览器，Firefox 同样需要在 about:config 中手动开启，Safari 也仅提供部分兼容能力——整体来看，JPEG XL 浏览器支持现阶段仍处于逐步完善阶段。

JPEG XL 被不少业内人士视为下一代开放式图像标准，目标就是替代传统 JPEG 格式。在相同视觉质量下，JPEG XL 的图像压缩效率提升明显，文件体积最高可缩小约 60%；同时它还具备出色的解码性能，对提升网页加载速度、优化页面体验和降低带宽消耗都有直接帮助。过去二十多年里，JPEG 一直主导互联网图片生态，但随着高分辨率、宽色域、HDR 等新需求不断增长，JPEG 在压缩率、功能扩展和图像表现力上的局限也越来越突出。因此，业界始终希望有一种更先进、更灵活、更加开源的图像格式能够真正落地应用。

回过头看，早在 2022 年，Google 曾主动移除 Chrome 中 JPEG XL 的实验性支持。当时给出的理由也很现实：网站实际采用率偏低，产业链上下游生态尚未成熟，继续投入维护资源的性价比并不高。此外，Google 本身也深度参与了 AVIF 格式的推进与标准制定，并持续大力推广这一方案，自然也希望进一步提升自己在 Web 图像标准领域的话语权和影响力。

时隔两年，Google 为什么又重新调整策略？背后其实有多重因素共同推动。

首先，苹果和 Mozilla 已陆续在 Safari 与 Firefox 中加入 JPEG XL 支持。这样一来，Chrome 反而成为唯一缺失该格式支持的主流浏览器，在市场和开发者视角下显得比较被动，兼容性短板也更加明显。其次，PDF 协会已在 2025 年底正式将 JPEG XL 列为 PDF 规范中嵌入 HDR 内容的首选图像编码方案。这意味着，如果 Chrome 内置 PDF 查看器希望完整渲染新一代 PDF 文档中的 HDR 图像内容，就必须重新支持 JPEG XL，这已经不只是选择题，而是明确的技术刚需。

此外，从开发者调研反馈来看，JPEG XL 也被列为浏览器图像支持领域的重要痛点之一。尤其是在渐进式加载、动画支持、高质量压缩等高级能力方面，内容平台、图像处理工具开发者以及 Web 应用团队都表现出较高关注度，对其后续落地和普及抱有很强期待。

这次重新支持 JPEG XL，Google 并没有继续沿用过去的 C/C++ 实现，而是全面切换为基于 Rust 编写的 jxl-rs 解码器。Rust 天生具备更强的内存安全特性，能够有效减少缓冲区溢出、空指针解引用等传统语言中常见的高风险漏洞，从而显著降低长期维护过程中的安全隐患与工程负担。对 Google 而言，Rust 不仅提升了代码可靠性和可维护性，也为在亿级用户规模下更安全地启用新一代图像格式打下了坚实基础。

对于前端开发者、网站运营团队以及内容平台来说，随着 Chrome 重新补上这一关键兼容环节，JPEG XL 在桌面端与移动端主流浏览器中的支持闭环正在加速形成。接下来，无论是在网页图片优化、PDF 渲染、富媒体应用，还是 WebAssembly 图形处理管线等场景中，JPEG XL 的实际部署和规模化落地，都很可能进入真正提速的新阶段。