三年前谷歌亲手砍掉的格式，如今自己请了回来。2026年10月6日，Chrome 155正式启用JPEG XL图片解码支持——一个比JPEG压缩率提升30%–50%、支持无损压缩、HDR和渐进式解码的下一代图像格式。但比格式本身更值得关注的，是谷歌重返这条路的方式：一个用Rust从头重写的解码器、一次历时四年的开发者施压、以及一场牵动三大浏览器引擎的标准博弈。
被遗忘的57%
先看一组数字。根据2025 Web Almanac的数据，JPEG至今仍占LCP图片的57%，WebP增长到11%，而AVIF——那个被无数开发者视为“JPEG终结者”的格式——实际占比仅0.7%。中位数网页加载19张图片，总重911 KB。如果全部换成JPEG XL，每页能省下约450–550 KB。对于一张动辄数MB的网页来说，这是从“慢”到“快”的质变。
Chrome 155的更新日志里有三件事值得单独拎出来。
一个是解码器选型。谷歌选择了纯Rust编写的jxl-rs解码器，而非沿用原有的C++参考实现libjxl。图片解码器是浏览器攻击面中最危险的环节之一——处理不可信二进制数据的模块，一旦出现缓冲区溢出或释放后使用，攻击者便能逼近沙箱的底层防线。Rust从编译器层面切断了整类内存错误。
另一个是性能。jxl-rs团队利用了Rust nightly中刚稳定的target_feature_11特性，在不使用unsafe代码的前提下直接调用SIMD指令。由此构建的jxl_simd抽象层，让安全代码也能达到硬件级加速。叠加模糊测试和AI代码审查，谷歌官方确认：整个实现周期内未发现任何内存安全漏洞。
第三个，是这个决定的诞生逻辑——它不是一次自上而下的标准推动，而是一个被社区硬拉回谈判桌的反转故事。
时间线很清晰。2022年末，谷歌宣布从Chrome中移除JPEG XL的实验性支持，理由写得很官方：“没有足够的生态兴趣”。但开发者社区的反应在社交媒体和Chromium bug tracker上持续发酵，并未立即改变局面。真正的转折来自一个意想不到的方向——竞争对手。
2023年6月，Apple在Safari 17中实现了原生JPEG XL支持，覆盖Mac、iPhone、iPad全生态。微软在2025年3月通过Windows 11 24H2更新加入JXL支持。2025年10月，PDF协会宣布将JPEG XL纳入PDF规范，CTO Peter Wyatt说得很直白：“我们需要一种支持HDR内容的新图像格式。JPEG XL是我们的首选方案。”
当苹果、微软和PDF协会都站定了阵位，谷歌就成了那个唯一缺席的大厂。2025年11月，Chromium团队发布反转声明。2026年1月，Rust解码器jxl-rs被合并进Chromium代码库。2月，Chrome 145在flag后提供支持。10月6日，Chrome 155正式默认启用。同一天，Firefox 158被列为默认启用，定于一周后的10月13日上线。
三大浏览器引擎——Blink（Chrome）、WebKit（Safari）、Gecko（Firefox）——在JPEG XL上罕见地达成了一致。这件事本身，比格式的技术参数更具深意。
Rust：安全赌注背后的范式验证
JPEG XL不是新格式。它是ISO/IEC 18181标准，2021年正式发布，由Cloudinary的FLIF和Google的PIK融合而成。它的技术优势早在标准化前就被公认：对摄影类内容有近乎无损的压缩效率、支持HDR和宽色域、精细渐进式解码。问题从来不是“这格式好不好”，而是“谁敢在生产环境里用它”。
一个100,000行多线程C++的libjxl参考解码器，对浏览器渲染进程来说是一个巨大的攻击面。Mozilla在2024年9月明确表态：没有基于Rust的解码器，Firefox不会默认启用JPEG XL。
jxl-rs的诞生打破了安全与性能之间那道经典的跷跷板。它的核心突破不在于重写，而在于用Rust的安全承诺换来了浏览器厂商安全团队的信任。当模糊测试砸入数百万个随机输入、AI代码审查扫过每一条分支路径，依然找不到一个内存安全漏洞时，安全审查的逻辑就变了——从“这道门能不能开”变成了“这门早就装了自动锁”。
这对Web生态的影响远不止JPEG XL一个格式。一旦纯Rust图片解码器的路径被验证成功，音频解码（Opus/FLAC）、视频解码（AV1/H.266）、字体解析——凡是涉及从不可信网络数据中解析二进制结构的模块，都可能被逐一代入相同的Rust重写路径。Chrome用jxl-rs开了一条路，这条路不会止步于图片格式。
苹果赢了一个身位，微软跟上了节奏
谷歌弃用JPEG XL的四年里，最大的制度性受益者是谁？Apple。
当Chrome在2022年砍掉JPEG XL时，Safari团队选择了一条截然相反的路。2023年6月，Apple在Safari 17中实现了原生JPEG XL支持。这意味着如果你的受众以Apple用户为主，JPEG XL早在三年多前就已可用——不是“能用”，而是原生解码、不必降级、没有flag。
Chrome用户等了整整四年。即使算上2026年2月的Chrome 145（功能标记阶段），Chromium生态在JPEG XL上的空白期也超过三年。这个时间差意味着，任何以图像为主业的Web应用——摄影平台、设计工具、电商——如果要同时覆盖Safari和Chrome用户，不得不在两种格式之间做兼容层。苹果用一个“先走一步”的决策，让自己生态内的用户体验领先了整整三年。
微软也抓住了一个关键窗口。2025年3月，Windows 11 24H2加入JXL原生支持。加上PDF协会将JPEG XL纳入PDF规范，当一种图像格式同时穿透了浏览器、操作系统和PDF三个生态层级时，它的不可替代性就不再是“高保真图片”这样的小众叙事，而是成为出版、存档、专业影像这些真实商业场景的基础设施。
AVIF与JPEG XL：不是替代，是互补
任何一个经历过WebP到AVIF过渡的开发者都会问：我已经用上AVIF了，为什么还需要JPEG XL？
答案藏在两种格式的设计哲学差异里。AVIF基于AV1视频编码框架，在有损压缩的低码率区间表现优异——低于0.4 bpp时，AVIF在图像光滑度和伪影控制上明显优于JPEG XL。这也是为什么AVIF在2026年已覆盖约95%的全球浏览器，成为Web开发的事实默认。
但JPEG XL在三个维度上拥有AVIF至今不具备的能力。
第一是无损JPEG重新压缩。JPEG XL可以将现有JPEG文件无损地再压缩约20%，同时保留原始比特流的所有信息。对于拥有百万级JPEG照片库的摄影师、媒体机构和存档机构来说，这是成本最低的升级路径——不用动原文件，只做一次批处理，就能省下五分之一的存储空间，且随时可还原。
第二是HDR和宽色域原生支持。JPEG XL支持高达每通道32位，对比JPEG的8位是一个质的飞跃。对于HDR显示器和Apple的XDR屏幕来说，图片可以在浏览器中以完整动态范围直接显示，不需要额外的色彩管线转换。
第三是精细渐进式解码。JPEG XL从模糊缩略图平滑过渡到全分辨率，这个体验在网速不稳定或图片超大时尤其重要。而AVIF的渐进式支持至今有限。
谷歌官方的推荐出人意料地坦诚：“我们建议同时尝试AVIF和JPEG XL以获得最佳效果。JPEG XL在高保真或无损压缩场景中最有用，特别是摄影图像或需要精细渐进解码的情况。”
翻译成开发者能听懂的语言：压缩率是AVIF的赛道，保真度是JPEG XL的护城河。两者不冲突，也不替代。未来的Web图像管线不是“选A还是选B”，而是同一个picture标签里列两个source。
开发者信号如何改写了Chrome的产品路线图
Chrome重返JPEG XL的故事里，还有一个不那么技术、但同样值得深挖的维度：开发者反馈的力量。
在Web标准的制定史上，谷歌长期扮演着“规则制定者”的角色——从WebP到FLAC到PNaCl，Chrome的习惯是强势推进自己认定的方向，市场自然跟从。JPEG XL是近几年少见的反例：一个被谷歌单方面放弃的格式，通过社区多年的持续施压——bug投票、Interop Proposal、社交媒体讨论、调查问卷排名靠前——硬是把同一家公司拉回了谈判桌。
谷歌官方博客中有一段话值得全文引用：“我们的决策基于来自Web开发者的持续反馈和请求，这在Interop 2026流程和之前的多年提案中最为明显。”
这段话的关键词是“持续反馈”——不是一次爆发，而是多年累积的信号。Interop 2026中JPEG XL成为热门提案（popular proposal），State of HTML调查中JPEG XL支持被列为开发者最痛的点之一。当苹果已支持、微软已支持、PDF协会已采纳、Firefox更新了立场——谷歌如果继续停留在“生态兴趣不足”的旧判断上就会越来越孤立。
这是Web标准制定中罕见的“被社区反推”案例。它说明了一个事实：当足够多的利益相关方在足够长的时间里发出同一种声音，即使是Chrome也会让步。
多格式共存的终局
JPEG XL在Chrome中的回归，表面上解码的是一个格式，背后释放的信号却比格式本身更大。
第一，安全的成本在降低。jxl-rs证明了Rust可以在保证内存安全的前提下实现和C++解码器同等甚至更优的性能。浏览器大厂苦C/C++内存漏洞久矣，一旦这条路径走通，音频、视频、字体等其他攻击面模块的重写只是时间问题。
第二，多格式共存是新常态。AVIF赢在通用压缩，JPEG XL赢在高保真和专业场景。Web标准的终局不是“一个格式统治所有”，而是同一个picture标签里列三个source——jxl、avif、webp——按浏览器能力和内容类型动态选择。
第三，开发者正在获得更多话语权。一个被Chrome放弃的格式，依靠社区长达四年的信号输出，最终重返主流程。这件事本身在Chrome历史上并不多见。
JPEG XL不是来杀死AVIF的。它是来填补AVIF留下的那道窄缝——而对摄影师、HDR内容创作者和存档机构来说，那条窄缝恰恰是全部的意义。格式战争的终局只信奉一个规则：不是最强的活到最后，是最适配的赢。
快报