JPG vs PNG vs WebP vs AVIF：2026 年如何为网页选对图片格式

如果你的产品在网上分发图片，所选格式对页面体积的影响几乎超过任何其他单一决定。一张 4 MB 的首屏图和一张 180 KB 的首屏图，能决定网站在不稳定的 4G 网络下、用一台中端 Android 手机看时是「秒开」还是「爬行」。2026 年值得关注的主流格式有四个：经典的 JPG、无损的 PNG、如今无处不在的 WebP，以及越来越成熟的 AVIF。

本文会讲清每种格式底层是怎么工作的、节省的字节从哪儿来、你要付出什么代价，并给出清晰的选型建议。读完之后，「2026 年网页最佳图片格式是什么」这个问题，你就能不用打太极地回答；当周五傍晚 5 点，设计师扔给你一张 28 MB 的 PNG 截图时，你也知道该怎么办。

四位主角

JPG（也写作 JPEG）于 1992 年标准化，至今仍是绝大多数相机的默认输出格式。它在 8×8 的块上做离散余弦变换（DCT），对频率系数做量化，再用哈夫曼编码。设计上就是有损的，没有 alpha 通道，但解码极快、便宜，过去三十年里造出的几乎所有设备都支持它。

PNG 出现于 1996 年，作为 GIF 的无专利替代品。它在可选的行过滤之上使用 DEFLATE（与 zip/gzip 相同的算法），完全无损。PNG 支持真正的 8 位 alpha 通道、索引调色板，甚至每通道 16 位色彩。代价是体积：照片类内容用 DEFLATE 压缩效果不佳。

WebP 由 Google 于 2010 年发布，约在 2020 年获得全浏览器支持。有损 WebP 用 VP8 的帧内编码（与 VP8 视频编解码相同的预测模式）代替单纯 DCT，无损 WebP（VP8L）则使用一种带颜色缓存与预测变换技巧的定制格式。WebP 在两种模式下都支持 alpha，并支持动画。

AVIF 是 AV1 视频编解码（2018 年定稿，到 2024 年几乎全平台支持）的静态图像剖面。它使用更大、更智能的预测块、更多变换选项，以及远比 VP8 优秀的熵编码器。AVIF 支持最高 12 位色深、alpha、HDR 和动画。

压缩到底是怎么工作的

JPG 把图像切成 8×8 的块，每块做一次 DCT，再用量化矩阵除掉系数。高频被压得比低频更狠，因为人眼对细节不那么敏感。低质量参数其实就是把量化矩阵整体乘以更大的标量。这就是为什么 JPG 的伪影看起来像硬边周围的块状振铃——编码器实在「付不起」描述边缘所需的高频系数。

PNG 完全不做感知压缩。每行像素前面加一个字节的滤波器前缀（None、Sub、Up、Average、Paeth），用邻居预测每个像素，然后用 DEFLATE 压缩残差。如果是照片，残差仍是高熵噪声，省不下多少；如果是充满纯色块和锐利边缘的截图，节省就非常可观。

WebP 有损借鉴了 VP8 的空间帧内预测：每个 4×4 或 16×16 的块从已解码的相邻像素中按十种预测模式之一进行预测，只对残差做变换和量化。预测越好，残差越小，需要的比特越少。无损 WebP（VP8L）更进一步，使用定制的颜色缓存、调色板变换和上下文自适应的熵编码器。

AVIF 本质上是把一整套现代视频关键帧编码器搬过来。块大小从 4×4 到 128×128，变换包括多种尺寸的 DCT、ADST 和 identity，并有 56+ 种帧内预测模式，包括细角度粒度的方向预测。其类 CABAC 的算术编码器每比特携带的信息明显多于 JPG 的哈夫曼表。结果是在相同视觉质量下文件大约比 JPG 小 50%，代价是编码耗时大幅增加。

一眼看清文件大小

同一张 4000×3000 照片（白天风景，无透明）：
JPG  (q=85)   ->  1,180 KB
JPG  (q=92)   ->  1,940 KB
PNG  (24-bit) -> 12,420 KB
WebP (q=85)   ->    810 KB
WebP (lossless) -> 9,860 KB
AVIF (q=60)   ->    495 KB
AVIF (q=80)   ->    760 KB

同一张 1920×1080 UI 截图（纯色平面、锐利文字）：
JPG  (q=92)   ->    410 KB（文字边缘明显发虚）
PNG  (8-bit indexed) ->  92 KB
PNG  (24-bit) ->    280 KB
WebP (lossless) ->  74 KB
AVIF (lossless) ->  88 KB

从这些数字可以总结两点。第一，在自然照片上，AVIF 在相同感知质量下大约比 JPG 小 40%–60%、比 WebP 小 30%–40%。第二，对截图、UI 导出这类合成内容，无损 WebP 通常稳赢，PNG-8（当调色板放得下时）紧随其后。

2026 年的浏览器支持

JPG 和 PNG：100%。没什么好讨论的。任何有浏览器的地方都支持，包括十年前的 Android 平板和你早已忘掉的嵌入式 WebView。

WebP：几乎覆盖 100% 的浏览器流量。Safari 在 2020 年的 iOS 14 和 macOS Big Sur 中支持，Chrome 和 Firefox 支持时间更早，多数 in-app 浏览器现在也能解码。到 2026 年，对一般消费类网站来说，不提供 JPG 回退而直接发 WebP 已不再激进。

AVIF：2026 年大约覆盖 95%–97% 的浏览器。Chrome、Edge、Firefox、Safari（16.4+）以及主要 Android WebView 都能解码。剩下的缺口主要是很老的 Android、一些老智能电视上的嵌入式 WebView，以及企业锁定设备的长尾。对面向公众的网站，AVIF + WebP/JPG 回退是稳妥的默认。

透明、动画与色深

JPG 完全没有 alpha 通道。任何形式的透明都不能用它，这是设计师明明不该用 PNG 却用 PNG 的最常见原因。

PNG 提供真正的 8 位 alpha 通道，每个颜色通道支持最高 16 位，因此在图形管线中作为高精度中间格式很有用。标准 PNG 没有动画；APNG 存在，但出贴纸/表情之外的支持参差不齐。

WebP 在有损和无损模式下都支持 alpha，并且动画支持扎实，比动画 GIF 高效得多。色深是每通道 8 位，对绝大多数网页内容足够。

AVIF 支持 alpha、动画、10 位和 12 位色彩、广色域和 HDR 传输函数。如果你要发布 HDR 摄影或广色域艺术作品，AVIF 目前是唯一能忠实承载这些数据的主流网页格式。

硬件解码与能耗

JPG 在现代硬件上解码极其便宜，事实上几乎可以忽略；2015 年的手机解码 JPG 也比屏幕显示还快。PNG 的逐像素解码更重一些，因为 DEFLATE 对并行不友好，但截图场景下 PNG 的载荷通常更小，所以实际上互相抵消。

WebP 有损解码沿用十多年来移动芯片就有的 VP8 硅路径，又快又省电。无损 WebP 解码在多数芯片上是软件实现，但仍在预算之内。

AVIF 才是有趣的地方。AVIF 的软件解码确实比 JPG 或 WebP 重，单张图像有时慢三到五倍。好消息是，2022 年之后的多数手机都有 AV1 硬件解码，浏览器可以把静态 AVIF 走硬件路径——这些设备上 AVIF 实际和 JPG 一样快、甚至更快。在没有 AV1 硅的老笔记本上，一墙的 AVIF 缩略图解码会在 CPU 火焰图里冒头，所以请审慎使用，并依靠响应式图片标签，确保解码的永远是最小尺寸变体。

什么时候用哪种：简短版

• JPG 用于追求极致兼容、又不想维护多种变体的照片。质量 82–88 通常是甜区。
• PNG 用于截图、UI 导出、硬边缘的 logo，以及任何需要无损透明的场景。如果调色板放得下，优先用 8 位索引 PNG。
• 在 2026 年把 WebP 作为默认网页格式：有损 WebP 用于照片，无损 WebP 用于本来要用 PNG 的 UI 资源和图标。
• 当带宽和 Core Web Vitals 最关键、当你在分发 HDR 或广色域内容，或想拿到最小的 LCP 图像时，用 AVIF。务必通过 picture 元素配 WebP 或 JPG 回退。
• 完全不用 GIF。同等字节预算下，动画 WebP 和 AVIF 又小又好看。

一个实用的转换流程

多数团队不需要复杂的构建流水线就能享受现代格式。最小可用流程很简单：把相机或设计工具的原始导出保留为唯一可信源，在部署时生成 JPG、WebP 和 AVIF 三套变体。一次性转换则用 CLI 几秒搞定。

# 把一张照片转换为三种现代变体
cwebp -q 85 hero.jpg -o hero.webp
avifenc --min 20 --max 30 -s 6 hero.jpg hero.avif

# 用 picture 元素让浏览器选择它能识别的最佳格式
# <picture>
#   <source srcset="hero.avif" type="image/avif">
#   <source srcset="hero.webp" type="image/webp">
#   <img src="hero.jpg" alt="..." width="1600" height="900">
# </picture>

如果你不想装命令行工具、手头只有几张图，Multilities 在 /tools/image-convert 提供了基于浏览器的图片转换工具，支持 JPG、PNG、WebP、AVIF 之间任意方向转换，文件不会上传到任何地方，全部在你的标签页里完成。要在不改格式的前提下挤出 JPG 或 PNG 的多余字节，/tools/image-compress 会按你选定的质量重新编码，并展示压缩前后的字节数。

WebP vs PNG：永远问不完的问题

2026 年最常见的困惑仍然是 WebP 和 PNG 怎么选。简单答案：对几乎所有网页用例，无损 WebP 都严格优于 PNG。它更小，同样支持 alpha，你关心的每一种浏览器都能解码。如今继续用 PNG 的理由只有两个：一些下游工具链不接受 WebP（部分广告网络、部分老的 CMS 插件、部分印刷流程），以及 PNG 在设计师之间已经成为事实上的交换格式。

如果你在搭建一个新产品，资源管线应默认把 UI 资源用无损 WebP，把照片用有损 AVIF，仅在某个环节拒收现代格式时才退回 PNG 或 JPG。

常见坑

• 不要把 JPG 以更高质量再编码一次 JPG 还指望文件更好看。原始的量化已经丢了信息，你只会让文件更大。
• 不要把截图存成 JPG。文字周围的块状振铃显眼且无法挽回。用 PNG 或无损 WebP。
• 注意色彩配置文件。AVIF 和现代 WebP 编码器默认保留 ICC profile；老工具会剥掉，于是在广色域屏幕上颜色会偏。
• 试一下你 AVIF 编码器的质量刻度。不同编码器约定不同：libavif 用 0–100 的 quality；avifenc 历史上用 0–63 的量化器 min/max，越低越好。
• 如果你用的 CDN 会按需重编码，确认它确实根据 Accept 头协商了 AVIF。许多 CDN 默认只回 WebP，除非你打开某个开关。

JPEG XL 怎么样？

JPEG XL 是个真正优秀的格式，技术上能与 AVIF 抗衡，并独有一手：可以把现有 JPG 无损转码、体积大约小 20%。截至 2026 年，Safari 已经原生支持，Firefox 在标志位后支持，Chrome 仍未默认开启。在这种情况发生变化之前，把 JXL 当作值得关注的格式而非可部署的格式。AVIF 才是当下跨浏览器可用的现代格式。

30 秒决策树

如果是照片：生成 AVIF 和 WebP，回退到 JPG。如果有透明或锐利边缘：生成无损 WebP，回退到 PNG。如果你没法跑构建步骤：照片用 JPG，其余一律 PNG，然后该干嘛干嘛。2026 年图片格式不再是研究项目，答案大体已经稳定，工具链也已经成熟。选对格式，配好回退，把省下来的时间花在更重要的事上。