2026 年网页图片格式怎么选：JPEG 的帝国、AVIF 的崛起与 JPEG XL 的流放

拿一张 1200 万像素的照片（4000 × 3000 像素），用六种方式导出。PNG：24 MB。质量 90 的 JPEG：3.4 MB。视觉质量相当的 WebP：约 2.4 MB。视觉质量相当的 AVIF：约 1.7 MB。GIF 抖动压到 256 色上限：6 MB，画面里到处是明显的色带。SVG 不在这个名单上：它描述的是图形，而照片不是图形。

屏幕上是同一张图，磁盘上差了 14×。这个差距是工程问题，不是品味问题。每种格式都是在特定年份的约束下做出的一整套工程决策，而这些决策至今仍体现在你的页面体积里。

本文就是这个实验的决策版：每种格式到底对你的像素做了什么、2026 年年中哪些浏览器能解码它、网络实际在传什么，最后附一张可以直接贴进团队 wiki 的表。

参赛选手，逐个过一遍

JPEG（1992）。 机制：把图像切成 8 × 8 的块，用离散余弦变换把每个块换成频率，再按照人眼视觉模型把精细细节往零量化。强项：九十年代中期以来的每台设备都能解码，编码快，处理连续色调照片非常出色。弱项：没有透明，没有动画，锐利边缘和文字周围有可见的振铃，而且每重存一次，质量就往下叠一层。适合照片，以及任何必须在所有地方都能打开的东西。

PNG（1996）。 机制：完全无损。每条扫描线先用预测器滤波，再用 DEFLATE 打包——就是 gzip 里那套 LZ77 加 Huffman 的组合。强项：逐像素精确的输出，完整的 alpha 通道，所有地方都支持。弱项在照片：传感器噪声会让预测器失灵，一张 1200 万像素的照片相对原始像素只能压到 1.5:1 左右。适合截图、UI 抓图、示意图，以及任何带文字或平色的内容。

GIF（1987）。 机制：在最多 256 色的调色板上做 LZW 压缩，多帧打包进一个文件。仅存的强项是动画在任何地方都能播放，包括那些不支持现代格式的邮件客户端。弱项是其余的一切：256 色、一位透明，以及远超同等视频的体积。适合梗图和小型界面循环动画。

SVG（2001）。 机制：光栅意义上没有机制。SVG 是描述形状、路径和渐变的 XML，渲染器按屏幕需要的任何分辨率画出像素。强项：与分辨率无关，几何图形体积极小，可以用 CSS 控制样式。弱项：只对真正的矢量内容有效；塞了几千个节点和大量滤镜的文件，开销可能比一张位图还高。适合标志、图标、图表和示意图。

WebP（2010）。 机制：有损模式借用了 VP8 视频编解码器的帧内预测，无损模式用空间预测加 LZ77 风格的反向引用。强项：一个格式两种模式，有损模式下也有 alpha，支持动画，Google 自己的研究里同等质量下比 JPEG 小 25% 到 34%。弱项：16383 × 16383 像素的硬性上限，编码器比 libjpeg 更吃 CPU。几乎什么都适合——这正是它成为网络上 JPEG、PNG、GIF 默认升级路径的原因。

AVIF（2019）。 机制：AV1 视频编解码器的静态帧，包在 HEIF 容器里。强项：浏览器里能交付的最好的有损压缩，Netflix 2020 年的测试里同等质量下比 JPEG 小约 50%，外加 10 位和 12 位色深、HDR、alpha 和动画。弱项：编码是真的慢，没有渐进式渲染（图像要么一下子整个出现，要么完全不出现），极低质量设置下涂抹纹理的效果，比 JPEG 那种老实的块效应更难看。适合照片和头图这类对文件体积最敏感的场景。

HEIC（2015）。 机制：HEVC 静态帧，同样包在 HEIF 容器里。强项：压缩能力和 AV1 一个档次，而且是 2017 年以来每部 iPhone 的默认拍摄格式。弱项是法律而非技术：HEVC 裹在专利池里，苹果以外的浏览器厂商全都拒绝付钱。它属于相册，不属于网络。

JPEG XL（2021）。 机制：一个屋顶下两台引擎，有损用 VarDCT，无损用模块化模式，外加一个别家都没有的把戏——能把现成的 JPEG 无损重压到原来 80% 左右的大小，像素逐位不变。强项：渐进式解码，出色的无损压缩比，高保真摄影。弱项是普及度，这主要是一个关于浏览器政治的故事，下文会讲到。适合摄影流水线、归档，以及苹果设备上的网页。

浏览器支持，截至 2026 年年中

各格式默认开启的版本，数据来自 caniuse：

这张表里有三个细节值得注意。iOS 上的 AVIF 技术上在 Safari 16.0 就到了，但没有动画；16.4 才是 macOS 和 iOS 双双完整支持的版本。Edge 明明就是 Chromium，AVIF 却比 Chrome 晚了几年才上线，因为微软把解码器禁用得比 Google 更久。而 JPEG XL 那一行背后藏着一段不寻常的往事，下文专门用一节来讲。

全球覆盖率，按 caniuse 2026 年的数字：WebP 在 97% 左右，AVIF 在 93% 到 94%。JPEG 和 PNG 实际上稳定在 100%，这一点不太可能改变。

兼容性梯队

按覆盖范围划分，这些格式可以分成五层。

第一层是通用组：JPEG、PNG、GIF、SVG。每个浏览器、每个邮件客户端、每个操作系统的预览窗格、每台用了十几年的自助终端，全都能解码。如果文件必须保证能打开，就得用这四种之一交付。

第二层只有 WebP 自己。最后的主要抵制者是 Safari，而 Safari 14 在 2020 年 9 月补上了这块缺口。剩下的不过是 Internet Explorer 的存量和老旧的 Android WebView。对网站（注意，不是邮件）来说，WebP 作为稳妥的默认选择已经有五年左右。

第三层是 AVIF。Chrome 2020 年有了它，Firefox 2021 年，Safari 2022 年（2023 年 3 月的 16.4 才完整支持），Edge 在 2024 年 1 月默认开启。2024 年初以来，所有主流引擎开箱即用都能解码 AVIF。剩下的几个百分点是老 iPhone 和缺乏统一管理的 Windows 办公设备，兜底方案就是为它们准备的。

第四层是 JPEG XL，卡在了半路。苹果从 2023 年 9 月的 Safari 17 起原生支持。Google 在 2022 年底移除了 Chromium 的实验性解码器，随 2023 年 2 月的 Chrome 110 生效，随后改变方向，合并了一个基于 Rust 的解码器（jxl-rs），随 2026 年 2 月的 Chrome 145 上线，但仍需开启 flag。Firefox 的解码器在 flag 后面压了好几年。所以 2026 年年中的 JPEG XL 支持意味着：全体苹果用户，加上 Chrome 和 Firefox 用户里会去手动开启 flag 的那一小部分——这个群体太小，没法拿来当开发依据。

第五层是 HEIC：苹果平台上的 Safari 17，其他地方一概没有。这与其说是一个层级，不如说是一个单一厂商的生态。

网络实际在传什么

支持不等于使用。HTTP Archive 的 Web Almanac 爬取数百万真实页面、统计它们实际传输的内容，2024 年版（媒体数据最全的一期）读起来像一座缓慢移动的冰川。JPEG 仍是最常见的单一格式，占全部图像的 32%，但比 2022 年的 40% 整整掉了八个百分点。WebP 拿走了其中三个点，到了 12%。SVG 涨了约两个点。AVIF 到了大约 1%——听起来像四舍五入的误差，直到你换个角度，看相对增长：两年翻了将近 4 倍。ICO 占 1.3%，几乎全部是 favicon。而 GIF，37 岁高龄，居然也涨了一个点。

为什么动得这么慢？主要原因可以归结为三类阻力。CDN 缓存：图像按 URL 为键缓存在边缘节点上，换格式意味着整库清缓存、整库重编码。老设备：支持图表写着 97%，但缺的那 3% 集中在廉价安卓机和企业设备上，有些网站无法承受因为一张打不开的图而丢掉一单生意。工具链惯性：CMS 生成 JPEG 缩略图，因为它一直如此；设计工具导出 PNG，因为那是最大的那个按钮；而改默认值意味着去动一条没人认领的构建流水线。

还有编码成本。AVIF 的压缩优势是用编码时的 CPU 换来的，这就是为什么图像 CDN 要对它收费，也是为什么聪明的团队在构建或上传时预先生成 AVIF，而不是用到时临时转换。

接下来往哪走

未来几年里，AVIF 是最稳妥的选择。它在设计上就是免版税的（开放媒体联盟 2015 年由 Amazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflix 创立，明确就是为了逃离 HEVC 式专利池），一份规范同时包含有损和无损，支持 HDR，而且已经跨过了支持率门槛——跨过之后，兜底链的成本几乎为零。真正的代价是编码时间和缺少渐进式解码。前者可以用预生成解决，后者是可以接受的交换。

JPEG XL 本该得到比现在更好的结局。单论技术实力，它是有史以来标准化过的最完整的格式：渐进式解码、最好的无损模式、高位深摄影，还能无损重压缩整个现存 JPEG 语料库。Google 以生态兴趣不足为由把它从 Chromium 里移除，恢复请求成了 Chromium 问题追踪器历史上被标星最多的 issue 之一。三年后 Google 撤销了这个决定，但那时采用的窗口期已经基本关闭。JPEG XL 被流放的这些年，AVIF 陆续拿下了 CDN 集成、CMS 插件和默认勾选项。JPEG XL 会以归档师最爱和苹果设备一等公民的身份活下去。它在技术上具备成为主流的条件，却仍然错过了。

HEIC 不会成为网络格式。原因与质量无关。HEVC 解码需要专利许可，免费浏览器的厂商们十年来一直拒绝付这笔钱，而网络运行在免版税的技术之上。一个四大引擎里三家都不解码的格式不是网络格式，它是一个需要在边界上解决的导出问题。

与此同时，过渡技术已经完全定型，一共有两种形式。服务器端内容协商：浏览器发一个 Accept 头，列出自己能解码的格式，服务器或 CDN 为同一个 URL 挑出最优变体。客户端：<picture> 元素，列出候选项，浏览器取它能看懂的第一个：

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

最底下的 <img> 是万能兜底，任何环境都不会出岔子。这就是你一套站点同时给 93% 的人发 AVIF、给剩下的人发 JPEG 的办法。

决策表

关于 favicon 补充几句，因为表格那一行省略了一些细节。现代浏览器接受 PNG 甚至 SVG 的 favicon，但 ICO 仍是每个爬虫、每个 RSS 阅读器、每个上古浏览器标签页都认的唯一格式，而且一个 ICO 文件能把多个尺寸打进一个容器。如果你的标志现在是别的格式，JPG 转 ICO、WebP 转 ICO 和 PNG 转 ICO 可以直接在你的浏览器里生成规范的多尺寸 ICO。

格式之间怎么转换

大部分转换需求都能从上面的章节里推出来。到目前为止最常见的一个，是把 HEIC 从 iPhone 里弄出来、变成世界其他地方能打开的东西。要分享，HEIC 转 JPG 是正确的做法：HEIC 本身已经是有损，JPEG 能阻止损伤继续叠加。HEIC 转 PNG 把当前状态定住，方便编辑；HEIC 转 WebP 适合目的地是网站的情况。

然后是 JPEG、PNG、WebP 这三者之间的相互转换。把 JPEG 放进设计流程：JPG 转 PNG——不是因为它能提升质量（不能），而是因为它到此为止、不再继续损失。压小了上网：JPG 转 WebP。反方向找回旧软件兼容：WebP 转 JPG 和 WebP 转 PNG。一张要进相册的 PNG 截图：PNG 转 JPG；想更小又要保留透明，用 PNG 转 WebP。手里要是继承了未压缩的 BMP 扫描件，BMP 转 JPG、BMP 转 PNG 和 BMP 转 WebP 哪个都比把几 MB 的老古董发来发去强。连文档都会撞上同一个岔路口：照片类页面选 PDF 转 JPG，文字必须保持锐利选 PDF 转 PNG，页面要上网就选 PDF 转 WebP。

这些工具全部在你的浏览器本地完成转换，文件不会离开你的设备。

格式一直在变，规则不会变：让编解码器匹配内容，内容换了用途，就做转换。