WebP 转 AVIF
把 WebP 文件拖到下方，即可得到 AVIF 文件。转换在你自己的设备上完成，因此不会上传，除了浏览器内存上限之外没有任何大小或数量限制。
把图片拖到这里
Ctrl/⌘ V粘贴截图或复制的图片
支持 WebP
数值越低文件越小。照片用 75 通常就够。
100% 本地处理 文件不会被上传。
为什么要把 WebP 转成 AVIF？
同一张图片，AVIF 的体积通常明显小于原始的 WebP。当你在压缩页面体积、或者要挤进某个上传大小限制时，这一点很关键。
两种格式都是有损的。每一次重新编码都会再丢掉一点细节，所以最好从原图开始转，而不是从一张已经反复转过几轮的副本开始。
这两个都是现代网页格式，而 WebP 本身已经不错，所以诚实的第一个问题是：这个转换到底值不值得做。AVIF 确实明显更高效 —— 但你的起点是一张已经过了一遍有损编码器的图，这会大幅改变这笔账。
转换之前
宣传的收益前提是你从原件出发
通常引用的 AVIF 对比 WebP 的数字，前提是两者都从同一张未经处理的源图编码而来。从 WebP 编码 AVIF 是第二次有损处理：WebP 丢掉的细节已经不在了，而 AVIF 现在要花字节去忠实复现 WebP 留下的痕迹。这个方向上的真实节省通常只有宣传数字的一个零头。如果原始文件还在任何地方存着，请从它出发编码 —— 这个差别不小。
你同时也在交出一部分兼容性
WebP 已经有多年的全面浏览器支持，老设备构成的长尾大多已经淘汰。AVIF 来得更晚，那条长尾至今仍明显更长 —— 一些应用内浏览器、老手机和多数邮件客户端不会渲染它。对一个已经在顺利投放 WebP 的站点，省下的那点字节未必值得你去加一层原本不需要的兜底。
什么时候它确实说得通
大幅的照片类主视觉图，那是 AVIF 优势最大、而几百 KB 确实能撬动加载指标的地方。至于图标、小缩略图和纯色图形，收益微乎其微，而且有损 AVIF 还可能让边缘发虚 —— 那些就留在 WebP 好了。
会保留下来的
- 透明通道
- 像素尺寸
- 进一步的一些体积缩减
过不来的
- 一点细节 —— 这是第二次有损压缩
- 老设备与邮件客户端的支持
- 动画，如果源文件有的话
WebP 与 AVIF 对比一览
| 属性 | WebP | AVIF |
|---|---|---|
| 压缩方式 | 有损 | 有损 |
| 透明通道 | 支持 | 支持 |
| 典型文件大小 | 约为同等 JPEG 的 65-75% | 约为同等 JPEG 的 40-55% |
| 兼容性 | 所有主流浏览器和绝大多数应用都支持 | 所有现代浏览器支持；部分老旧桌面软件尚未跟进 |
| 常见来源 | 为减小页面体积而优化的网站 | 为减小页面体积而优化的网站 |
常见问题
我的 WebP 文件会被上传到哪里吗？
不会。解码器和编码器是运行在本页面内的 WebAssembly 模块。首次使用某种格式时，网络面板可能会显示编解码器下载，但没有任何请求会包含你的文件。在支持离线缓存的浏览器中，用过一次的编解码器会被缓存，之后同类转换可以断网完成。
有文件大小或数量限制吗？
我们不设任何限制。实际上限取决于你设备的内存，因为转换过程中图片需要以未压缩形式驻留内存。在普通笔记本上，一亿像素以内的图片通常都能顺利转换。
转成 AVIF 会损失画质吗？
AVIF 是有损格式，会丢弃部分数据。在默认质量下，正常观看尺寸几乎看不出差别。如果你需要像素级完全一致的副本，请改选 PNG。
手机上能用吗？
可以。同样的 WebAssembly 模块在移动浏览器上也能运行。由于手机 CPU 较弱，转换会比桌面端慢，超大图片也更容易触及内存上限。
我手上怎么会是个 WebP 文件？
现在多数网站都改用 WebP，因为它比 JPEG 更小，所以从网页上保存图片往往就得到一个 WebP。浏览器对它支持良好，桌面软件则明显差一截——这正是把它转走成为高频需求的原因。
AVIF 到底在哪些地方能用？
所有主流浏览器都能原生解码 AVIF，因此用在网页上是安全的。桌面软件则落后不少，很多看图和修图软件仍然打不开它。此外它的编码速度明显慢于这里的其他格式，大图需要等上几秒。