往网页里放一张图，随手保存成 PNG 可能几百 KB，截图工具的默认输出可能更大。图片通常是页面流量的大头，格式选错，等于让用户为同样的视觉效果多付几倍流量。而「该用什么格式」这个问题，隔几年就要重新回答一次------2026 年 11 月这个节点，答案和三年前已经不一样了。
这篇笔记以 MDN 的《图像文件类型与格式指南》为底本，整理 GIF、JPEG、PNG、SVG、WebP、AVIF 六种常见格式的优缺点，再用 caniuse 的最新数据补上浏览器落地现状，最后给出可以直接照抄的选型建议。
一、先看诞生时间线
把常见网页图片格式按时间排在一起，以首版规范或首次公开发布为口径：
| 格式 | 诞生日期 | 对应事件 |
|---|---|---|
| GIF | 1987 年 6 月 15 日 | CompuServe 的首版 GIF87a 规范。原始规范 |
| JPEG / JPG | 1992 年 9 月 18 日 | ITU 批准 JPEG 压缩标准 T.81。ITU 标准记录 |
| PNG | 1996 年 10 月 1 日 | PNG 1.0 成为 W3C 推荐标准，格式本身在 1994 年 12 月开始形成。PNG 1.0 规范 |
| SVG | 2001 年 9 月 4 日 | SVG 1.0 成为 W3C 推荐标准，定位矢量图形格式。SVG 1.0 规范 |
| WebP | 2010 年 9 月 30 日 | Google 首次公开发布 WebP 开发者预览版。Chromium 发布公告 |
| AVIF | 2019 年 2 月 19 日 | 开放媒体联盟的 AVIF 1.0 规范日期。AVIF 1.0 规范 |
从 GIF 到 AVIF，这条路走了 32 年，WebP 比 AVIF 早问世约八年半。时间线里能读出两条规律。
规律一：每个新格式都踩在旧时代的痛点上。 GIF 诞生于拨号上网的 1987 年，解决的只是「把图传过去」；JPEG 用有损压缩摆平了照片的体积；PNG 是 GIF 的 LZW 编码专利风波（1994 年 Unisys 主张收费）逼出来的开源替代品，顺手补上了透明通道；SVG 把「图形描述」从像素网格换成矢量；WebP 与 AVIF 则都是视频编码技术的下放。WebP 取自 Google 收购来的 VP8，AVIF 取自开放媒体联盟的 AV1，编码器在视频帧内压缩上的积累，直接兑换成了静态图的压缩率优势。
规律二：诞生不等于能用，中间往往隔着五到十年。 WebP 2010 年发布，Safari 直到 2020 年的 Safari 14 才支持，整整等了十年；AVIF 2019 年定稿，到 2024 年初 Edge 121 补齐后，才算覆盖全部常青浏览器，用时约五年。所以评估一个新格式，光看规范发布日期没有意义，要看浏览器落地进度。这也是下文反复使用的判断标准。
二、逐个格式过一遍
GIF（1987）：全网兼容，但该退休了
GIF 用 LZW 做无损压缩，但只支持 8 位索引色（最多 256 色），只有单色透明（边缘生硬，没有半透明），动画部分也没有现代帧间压缩。它胜在「所有能显示图片的浏览器都认识它」，加上表情包文化加持，至今仍大量出现在网页上。
但 MDN 的建议很直接：静态图首选 PNG，动画考虑 WebP、AVIF 或 APNG。一条 10 秒的 GIF 动画换成 MP4/WebM 视频，体积通常能小一个数量级。今天还在往页面里塞 GIF，多数时候只是因为换格式麻烦，而不是 GIF 合适。
JPEG（1992）：照片的及格线
JPEG 实际是 JFIF 封装格式套着 JPEG 压缩数据，基于离散余弦变换（DCT）做有损压缩：不支持透明、不支持索引色，只有 8 位真彩色，尺寸上限 65,535×65,535 像素。
- 优点：兼容性很广，1992 年以来所有浏览器、图像工具、第三方平台都认它；照片类内容的压缩效率至今够用；支持渐进式编码，大图可以「先糊后清」地加载，弱网体验好。
- 缺点：无透明通道；有损编辑每保存一次劣化一次；高对比边缘会出现振铃伪影；8 位色深与 HDR 无缘。
2026 年它不再是照片的首选，但它是永远的回退格式。任何一个「不知道对方支持什么」的场景，JPEG 都是最大公约数。
PNG（1996）：无损与透明的基本盘
PNG 做无损压缩，支持 1/2/4/8/16 位灰度、真彩色与索引色，带完整 Alpha 透明通道，尺寸上限约 21 亿像素。
- 优点：像素精确，截图、UI 抓帧不丢细节；透明通道完善；16 位色深为专业场景留了余量。
- 缺点：对照片类内容，无损压缩的效率远不如有损格式，体积常常数倍于 JPEG。
定位很清晰：截图和需要精确像素的场景用它，照片别用它。
SVG（2001）：矢量图形的唯一答案
SVG 是基于 XML 的文本格式，用几何描述而非像素存储图形，可无限缩放；既能作为独立文件通过 <img>、background-image 使用，也能直接内嵌 HTML，还支持用 CSS 和脚本控制样式、动画与交互，通过 HTTP 压缩（gzip）后传输体积很小。
- 优点：图标、图表、示意图一次产出、全分辨率通用；能跟随站点明暗主题变色（本站封面就是这么做的）；内嵌时文字仍可被选中，对无障碍和 SEO 友好。
- 缺点：只适合「画出来」的图形，照片无缘；节点极多的复杂 SVG 解析与渲染成本可能高于位图；作为独立文件加载时注意不要内嵌脚本，避免安全问题。
图标、图表、示意图的默认答案就是它。
WebP（2010）：十年长跑的全能选手
WebP 的有损模式基于 VP8，比 JPEG 平均小 25%--35%；无损模式比 PNG 小约 26%；支持动画（ANIM/ANMF 块）与 Alpha 透明。
- 优点：一套格式同时覆盖「有损照片、无损截图、透明、动画」四种需求；2020 年 Safari 14 支持后，现代浏览器全数覆盖，兼容性已无死角。
- 缺点：有损模式以 8 位 YUV420 存储，色度抽样会让高对比的文字边缘发糊；尺寸上限 16,383×16,383 像素；不支持渐进式渲染。
它是今天的「默认安全牌」。不确定该用什么的时候，WebP 不会错。
AVIF（2019）：新科状元，2026 年起可以放心用
AVIF 取自 AV1 的帧内编码，由开放媒体联盟制定，免版税。压缩率是同类最强：有损模式比 JPEG 小约 50%，也优于 WebP（MDN 给出的中位数据：AVIF 压缩率约 50%，WebP 约 30%）。它还支持 10/12 位色深、HDR、宽色域、YUV444、无损压缩、Alpha 透明、动画和灰度。
- 缺点：编码慢，构建与 CDN 侧的 CPU 成本明显高于 WebP；不支持渐进式渲染，大图必须整张下载完才显示；动画支持在各浏览器落地有先后（Firefox 早期只支持静态图）。
- 兼容性：Chrome 85（2020 年）、Firefox 93、Safari 16.4（16.1 起部分支持）、Edge 121（2024 年初）。至此，所有常青浏览器都已支持 AVIF。MDN 中文页摘要里还留着「不支持 Edge」的旧说法，已经过时了。
照片与富媒体图片的首选，配 WebP/JPEG 回退。
顺带一提：APNG
Mozilla 主导的「会动的 PNG」：无损、真彩色、全主流浏览器支持，观感与体积都比 GIF 好，贴纸类场景常用它。但论压缩体积，动画 WebP 与动画 AVIF 更省。GIF 动画的直接升级位可以留给它，但新项目没必要主动选。
三、汇总对比
| 格式 | 压缩方式 | 透明 | 动画 | 色深亮点 | 浏览器支持（2026-11） | 一句话定位 |
|---|---|---|---|---|---|---|
| GIF | 无损（256 色索引） | 单色 | ✅ | 8 位索引 | 全部 | 旧动画格式，尽快替换 |
| JPEG | 有损 | ✗ | ✗ | 8 位 | 全部 | 照片回退与最大兼容 |
| PNG | 无损 | Alpha | ✗ | 16 位 | 全部 | 截图与精确像素 |
| SVG | 矢量描述 | ✅ | ✅ | 与分辨率无关 | 全部 | 图标与图表 |
| WebP | 有损 + 无损 | Alpha | ✅ | 有损 8 位 | 全部（2020 年补齐） | 默认安全牌 |
| AVIF | 有损 + 无损 | Alpha | ✅ | 12 位、HDR | 全部常青（2024 年补齐） | 照片首选 |
四、这些格式别再用
MDN 明确列出的「应避免」清单，理由也都干脆：
- BMP：基本不压缩，文件巨大，没有任何理由出现在网页上；
- ICO ：favicon 用 PNG 加
<link rel="icon" type="image/png">即可，ICO 只在需要兼容极老 Windows 时才考虑； - TIFF：扫描与印刷领域的格式，浏览器基本不支持（仅 Safari 把它当下载处理），网页不要碰；
- XBM：早已废弃，还有安全隐患。
五、2026 年这个节点怎么选
按内容类型的决策表
| 内容类型 | 首选 | 回退 |
|---|---|---|
| 照片 | AVIF | WebP → JPEG |
| 图标 / UI 元素 | SVG | PNG 或无损 WebP |
| 截图 | 无损 WebP | PNG |
| 图表 / 示意图 | SVG | PNG |
| 动画 | 视频（MP4/WebM）或动画 AVIF/WebP | APNG |
MDN 的建议表里照片首选写的是「WebP 或 JPEG」，那是「全兼容优先」的保守口径。如果你的访问统计里旧浏览器占比已经可以忽略（2026 年大多数站点是），照片首选应该上调为 AVIF。
回退的写法
<img> 标签本身不支持格式回退，需要用 <picture> 提供多个 <source>：
html
<picture>
<source srcset="photo.avif" type="image/avif" />
<source srcset="photo.webp" type="image/webp" />
<img src="photo.jpg" width="1200" height="800" alt="山顶日出" />
</picture>
浏览器按 source 顺序取第一个认识的格式，<img> 是最终回退，同时承载 width/height/alt。这三个属性别省，它们负责防布局偏移和无障碍。两三个 source 就足够，再多只是浪费构建产物。
2026 年的变数：JPEG XL
时间线之外必须单独说 JPEG XL。规范由 JPEG 委员会制定（ISO/IEC 18181，2022 年定稿），有损与无损压缩率都瞄准 AVIF 和 PNG 的位置，还统一支持渐进式渲染与动画，一度被看作「终极图片格式」。但它的浏览器落地极其曲折：
- Chrome 曾在 2023 年初的 110 版移除实验支持，引发社区激烈反弹；
- 2026 年态度反转：Chrome 155 起、Firefox 158 起、Opera 139 起默认开启（此前各有各自的 flag 阶段）；
- Edge 至今（至 156 版）全系不支持，Safari 17 起仅部分支持（只有静态图）。
caniuse 的 JPEG XL 数据目前给出的全球默认支持率约 54%，加上部分支持约 69%。结论：JPEG XL 是当下最值得盯的变量，但离「裸用」还有距离。MDN 的推荐清单也尚未收录它。新项目不必为它改造管线，存量站点可以在 CDN 层保持关注，等 Edge 与 Safari 补齐再谈全量切换。
工程侧的顺手做法
- 构建时自动出多格式：源文件一份、产物多份的管线已经成熟，Astro 内置的图像服务（基于 sharp）就能在构建时自动转换格式；
- CDN 自动协商 ：按请求的
Accept头自动返回 AVIF/WebP（如 Cloudflare Polish 或各家图片 CDN），存量站点改造成本最低的方案； - 验收别只看体积：AVIF 没有渐进式渲染，大图在弱网下是「白一块然后突然出现」，体验可能不如渐进式 JPEG，首屏大图值得做对比测试。
我自己博客的做法
这个博客本身就是一个可参考的样本：文章封面统一用能随明暗主题变色的 SVG 矢量图，构建时再为社交分享卡生成 WebP 伴生图；正文截图统一 WebP；分发到微信等不支持 WebP 的平台时，再实时转出 PNG/JPG。格式选型的收益不在「单张图省了多少」，而在几百张图的存量站点一年累积省下的流量与存储。
结语
拿到一张图，先问三个问题：
- 是矢量吗？（图标、图表、示意图）→ SVG；
- 是照片吗？ → AVIF，配 WebP/JPEG 回退；
- 其他位图（截图、需要精确像素）→ 无损 WebP，兜底 PNG。
最后送一句时间线教给我们的事：格式的「诞生」到「能用」往往隔着五到十年，盯浏览器落地进度，比盯压缩率论文更实用。
参考
- MDN：图像文件类型与格式指南（本文的底本，格式特性数据多出自此处）
- caniuse：AVIF、caniuse：JPEG XL（浏览器支持数据，2026 年 11 月查询）