约 7 分钟读完 · 更新于 2026-10-21 · 文中每条都能在下面的配套工具里动手验证
先换一个问题：决定格式的是「谁来解码」
大部分「该用哪个格式」的争论其实问错了。格式不是越新越好，而是取决于三件事：图片最终出现在哪里（自家 App、发给微信、放进网页、扔进设计稿）、对方设备能不能解这段编码、以及这张图的内容类型（照片、图标、文字截图、动图）。同一张电商主图，站内用 WebP、落地页用 AVIF、给印刷同事的原稿留 PNG，是同时成立的三个答案。先问「谁会打开它」，格式自然就定了。
五种格式的真实对照表
| 格式 | 压缩方式 | 透明 | 动画 | 解码成本 | 典型该用它的地方 |
|---|---|---|---|---|---|
| JPEG | 有损（可调质量） | 不支持 | 不支持 | 最低 | 照片原片、需要兼容老设备的存档 |
| PNG | 无损 | 支持 | 不支持（APNG 为扩展） | 低 | 截图、图标、需要像素级一致的图 |
| WebP | 有损 + 无损都有 | 支持 | 支持（单文件） | 低偏高 | 网页默认格式，绝大多数场景的稳妥选择 |
| AVIF | 有损（更狠） | 支持 | 不支持（动图仍需转 WebP/GIF） | 高，且吃硬件解码 | 面向现代浏览器、带宽紧张的场景 |
| SVG | 无损（可极限优化） | 支持 | 靠 CSS/SMIL | 极低，浏览器直接渲染 | 图标、插画、图表、需要改色与缩放 |
WebP：为什么它能当默认值
WebP 胜在覆盖面而不是单项冠军。它同时支持有损、无损、透明和动画，这意味着「把一堆 PNG 图标换成 WebP」和「把一堆 JPEG 照片换成 WebP」都是一次到位的事，不用为不同内容准备两套流程。相对 JPEG，官方给出的中位数体积收益在 25% 到 34% 之间；相对 PNG，透明图通常能降到三分之一左右，个别纯色界面图甚至更夸张。代价是它只有较新的解码器支持——不过这一点在今天的浏览器环境里基本已经不再是问题，需要照顾的老设备留在 JPEG 就好。
AVIF：更大的收益，三个必须付的代价
- 编码很慢。同画质下 AVIF 的编码耗时通常是 WebP 的十倍以上，一次性处理几千张图时要接受分钟级的等待，好处是可以离线跑一次、之后长期享受更小的文件。
- 解码依赖硬件。桌面与移动端的中高端机型没问题，但老设备、低端安卓机和部分老电视上，AVIF 的解码速度可能反而不如 WebP 划算，等于用体验换流量。
- 小尺寸不一定更小。AVIF 的优势在中等偏大的图片；几百像素的图标类文件，它相对 WebP 的优势常常被编码开销吃掉，甚至更大。
# 照片：JPEG → WebP，质量 78，保留 EXIF 之外的全部元数据
cwebp -q 78 -metadata none photo.jpg -o photo.webp
# 图标：PNG → WebP，无损 + 保留透明度
cwebp -lossless -z 9 icon.png -o icon.webp
# 面向现代浏览器再压一档：WebP → AVIF，慢但值得
avifenc -q 50 --min 32 --max 40 photo.webp photo.avif
# 批量：只挑大于 200KB 且长边超过 1600px 的图转 AVIF
find assets -name "*.jpg" -size +200k -exec avifenc -q 50 {} {}.avif \;<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." width="1200" height="630"> </picture> <!-- 关键：<img> 兜底必须给宽高，否则布局会跳 -->
JPEG 什么时候依然是对的
不是所有东西都值得升级格式。这几种情况留在 JPEG：一是要发给不确定客户端的场景（邮件附件、打印店、别人的设计软件），二是需要保留完整原始信息留档的时候——把相机 RAW 转成 WebP 意味着有损压缩，原始细节永久丢失，三是含大面积平滑渐变的天空、皮肤这类内容，WebP 和 AVIF 在极低质量下容易出现色带与块状噪点，反而不如质量适中的 JPEG 干净。存量照片永远不要「为了省空间」重压一遍，收益极小、风险很大。
SVG：不是「越小越好」的矢量题
从设计软件导出的 SVG 往往带一堆冗余：编辑器注释、多层空分组、写满六位的小数坐标、重复定义的样式、未用到的字体声明。这些用 <a class="faq-link" href="/tools/svg-optimizer/">SVG 优化工具</a>清掉之后，体积常能掉到原来的三分之一左右，渲染结果肉眼无差。反过来也有该把 SVG 退回位图的时候：图里嵌了整块位图数据、渐变和滤镜多到几十层、或者要在不支持完整 SVG 特性的设计软件里编辑——这些场景下光栅化后的 PNG 反而更小更快。判断标准是「优化后还剩多少元素」：路径数量上百就该考虑转位图。
一张图的正确处理顺序：先缩放，再转格式，最后压缩
- 先缩放到实际使用尺寸。用 4000px 的原图去填一个 400px 的位置，是所有体积浪费里最大的一笔，而且这一步与格式无关，先做收益最高。用 <a class="faq-link" href="/tools/image-resize/">图片缩放裁剪</a>按长边或宽度等比输出，顺便定好最终格式。
- 再转格式。目标确定之后再转，避免「先转 WebP、发现要改尺寸、再转回 JPEG」这种来回损耗画质。
- 最后按需压缩。格式定好后再调质量，观察体积与观感的实际平衡点，而不是照抄别人的固定数值。
- 顺手清 EXIF。转格式或重新编码时顺手去掉相机型号、拍摄时间与 GPS，既减小体积也避免位置信息外泄。
常见问题
WebP 和 JPG 到底该用哪个？
看解码方。站内 App、网页、聊天分享一律 WebP，同画质下体积通常小三成，透明图优势更大；需要兼容老设备、发给打印店、或者留原始档时保留 JPEG。用 图片格式转换两边各导一份对比一下实际体积和画质，半天就能定。
AVIF 浏览器支持怎么样，现在还能用吗？
主流浏览器都已支持，覆盖面上已经不是问题。真正的代价是编码慢（比 WebP 慢一个数量级）和老设备解码吃力，所以稳妥做法是网页上同时提供 AVIF、WebP、JPEG 三份，用
为什么我的 SVG 有 200KB，优化后还是很大？
通常因为里面嵌了一张位图（base64 data URI），或者滤镜、渐变层数太多。这类文件本质上是「用矢量格式装的图片」，优化器只能去掉冗余标记，压不动主体内容。正确做法是先确认它是否真的需要矢量：需要改色和无限缩放就继续瘦身 SVG，只是要贴到网页上就直接用 2 倍尺寸的 PNG/WebP。
把 PNG 转成 WebP 会损失画质吗？
默认会。PNG 转 WebP 在转换工具里通常按有损模式编码，细小文字和硬边缘可能出现发虚或色边。追求像素一致就用 WebP 的无损模式，体积会比 PNG 小但不会更小；折中做法是照片素材转 WebP 有损，界面图标和文字截图走无损模式。转换前后用 压缩工具的并排预览放大到 200% 看一眼再决定。