如何把 WebP 转成 AVIF
把 WebP 拖到上传区，或点击它来选一个文件。文件一到，转换就开始，没有单独的转换按钮。由于 AVIF 是最重的生成格式，单张图片会为了最好的结果被送到我们的服务器，AVIF 会以可下载的形式返回。小图远不到一秒就转好，2 百万像素的照片约一秒，800 万像素约几秒。AVIF 就绪后，点击下载，用相同的原名和新的.avif 扩展名保存。统计行会显示两个大小，下载链接会在大约 2 小时后删除。
正在加载您的文件…
把 WebP 转成 AVIF，文件更小且保留 alpha
把 WebP 转成 AVIF，得到小 20 到 30 个百分点且保留透明度的照片。
正在加载您的文件…
或将图片拖放到此处
转换中…
0%
正在转换您的图片
这可能需要一分钟左右——多个文件会稍久一些。请保持此标签页打开。
图片已转换为 AVIF
快速答案
几次点击就能把 WebP 转成 AVIF。由于 AVIF 是最重的生成格式，为了最好的结果，繁重的活由我们的服务器来做，所以转成 AVIF 可能会把图片送到我们的服务器。当你一次转换多个文件时，服务器总会处理这一批，下载链接会在大约 2 小时后删除。两种格式都是有损的，所以这是第二次有损处理，WebP 此前已经压掉的颜色细节会再被压一次。对照片而言，质量 85 下的结果在视觉上几乎没有可见损失，，输出通常比源 WebP 小 20 到 30 个百分点。如果你的 WebP 背景透明，alpha 通道会完整保留。坦白说，速度是弱点。一张 2 百万像素的照片用时不到一秒，800 万像素约几秒，更大的图片更久。会话里第一次转换可能要短暂预热。
AVIF 比 WebP 小多少
AVIF 构建在 现代格式 编解码格式之上，依据跨照片测试集的 与 比较，在相同感知质量下文件可比 WebP 小约 20 到 30 个百分点。在颜色平坦或边缘锐利的简单图形上差距收窄，WebP 能打平甚至胜出。最大的优势在照片上，正是当今多数现代站点里占据页面重量的图像。一张 的 WebP 在相当显示质量下转成 AVIF 后可能变成 noticeably smaller。对已被重度压缩的 WebP 源，省下的更少。AVIF 的浏览器支持如今已超过全球 93%，所以面向现代受众时，回退方案适用的情形已缩成一小撮。
WebP 转 AVIF 会保留透明度吗
会。WebP 支持 alpha 通道，AVIF 也支持，转换会原样带过去。透明背景的 WebP 会变成同样透明背景的 AVIF，没有白底填充、没有偏色、边缘没有光晕、也没有预乘 alpha 带来的意外。这与转成 JPG 正相反，JPG 没有透明，所以 alpha 会被毁掉。如果你的 WebP 里是抠好的徽标、界面图素或透明画布上的贴纸，AVIF 是一个安全的去处，你也无需先把图片扁平化。alpha 平面会与颜色数据一起以质量 85 保存，到达输出时柔和边缘依旧完好。
质量与转换速度
两种格式都是有损的，这一对运行在质量 85。在该设置下，照片约测得，对自然图像而言视觉上接近无损。边缘锐利或颜色平坦的图形可能出现轻微伪影。由于源本就是有损的 WebP，这是第二次有损处理，WebP 已经丢掉的信息无法找回。速度是 AVIF 压缩效率的代价。在 Chrome 桌面端，2 百万像素照片不到一秒，8 百万像素约 3 秒，2400 万像素约 10 到 30 秒。Firefox 约慢四倍，手机比桌面 Chrome 慢 3 到 5 倍。第一次转换还要付出一次性预热。
用于交付的 AVIF 浏览器支持
AVIF 如今覆盖全球超过 93% 的浏览器：Chrome 85 及以上、Firefox 93 及以上、Safari 16.4 及以上、Edge 121 及以上都原生显示。Internet Explorer、Opera Mini 以及 2022 年前的 Safari 不行。对交付而言，实际结论是一个提供 AVIF 并以 WebP 作回退的 HTML picture 元素，几乎能覆盖所有现代流量。对于需要兼顾剩余那几个百分点的站点，保留 WebP 回退。对于确信受众用现代浏览器的站点，单独用 AVIF 也可行。带宽的节省，使得 AVIF 优先加 WebP 回退在 2026 年成为注重性能的开发者中的主流做法。
你的文件在哪里处理
AVIF 是最苛刻的生成格式，所以这一对会用我们的服务器来交付最好的结果，也就是说转成 AVIF 可能会把你的 WebP 送到那里。处理发生，AVIF 返回，下载链接会在大约 2 小时后删除。当你一次转换多个文件时，服务器总会接手这一批，把结果汇成一个包，同样是大约 2 小时的窗口。万一服务器不可用，页面会改为在浏览器里生成单张图片，把那一个文件留在设备上。我们不保留账户、资料，也不保留你图片的副本，超过这个短暂的处理窗口就没有了。诚实地说：单张 AVIF 为了质量可能在我们的服务器上生成，一批总是这样，之后你的东西什么都不会留下。
工作原理
-
放入你的 WebP
把 WebP 拖到上传区，或点击它打开文件选择器，从你的设备里挑一个。
-
让它转换
AVIF 是最重的生成格式，所以图片会为了最好的结果被送到我们的服务器。下载会在大约 2 小时后删除。
-
查看大小
AVIF 就绪后，统计行会显示 WebP 源大小与 AVIF 输出大小。照片上 20 到 30 个百分点的下降很常见。
-
下载 AVIF
点击下载即可把文件保存到你的设备，沿用相同主文件名并换成新的.avif 扩展名。
相关转换
需要更广兼容时退回 WebP，或从无损 PNG 起步以省得更多。
常见问题
AVIF 比 WebP 更好吗
对面向现代浏览器受众交付的照片，AVIF 在压缩上胜出：依据跨照片测试集的 测量，在相同感知质量下通常小 20 到 30 个百分点。在颜色平坦、边缘锐利的图形上，WebP 仍有竞争力，偶尔还能做出更小的文件。两者都支持 alpha 和动画。如果你的受众用现代浏览器，目前约占全球用户的 93%，AVIF 是更好的默认。否则就把 WebP 留作回退。
WebP 转 AVIF 会损失质量吗
会，一些世代损失不可避免。两种格式都是有损的，所以把有损 WebP 在 AVIF 质量 85 下重新保存会加上第二次压缩。对照片而言结果视觉上接近无损，约测得。对边缘锐利或颜色平坦的图形，要预期轻微伪影。从有损 WebP 源得不到真正无损的 AVIF，因为 WebP 丢掉的信息在这次转换开始前早已不在。
AVIF 像 WebP 一样支持透明吗
是的。WebP 与 AVIF 都支持 alpha 通道，转换会精确带过透明，没有白底填充、没有偏色、边缘也没有光晕。这与转成 JPG 不同，JPG 没有透明，所以 alpha 通道会被完全破坏。如果你的 WebP 背景透明，你的 AVIF 也会，同样的柔和边缘和半透明像素都完好保留。转换前无需手动扁平化。
WebP 转 AVIF 要多久
会话里第一次转换约用一秒准备。之后，2 百万像素图片在 Chrome 上不到一秒，8 百万像素约 3 秒，2400 万像素可能要 10 到 30 秒。在 AVIF 上 Firefox 约比 Chrome 慢四倍，所以一张大图在 Firefox 上可能卡半分钟。手机比桌面慢 3 到 5 倍。对大文件或 Firefox 用户，桌面端的 Chrome 是最快的路径。
为什么保存 AVIF 比 WebP 慢
AVIF 构建在 现代格式 编解码格式之上，它施加的预测和熵编码远比 WebP 基于 的算法复杂。现代格式 的设计是以保存的复杂度为代价把压缩做到极致，用较慢的保存换取同类最佳的输出。AVIF 的解码在所有现代浏览器里都很快，因为硬件解码已是标配。但保存是繁重的活，一张大照片的运算确实密集，这正是它从不瞬间完成的原因。
什么时候该把 WebP 转成 AVIF
当你端到端掌控交付环境且受众用现代浏览器时，对照片及类照片内容从 WebP 升到 AVIF 是合理的，那里 20 到 30 个百分点的体积节省会转化为更快的 LCP 分数。对 WebP 本就紧凑的小图标或简单图形则吸引力较小，对保存时间会拖住流水线的高流量页面、或目标系统明确要求 WebP 的场合也是如此。
详细信息
团队关于工艺、格式以及一个好结果背后小决定的笔记。
为什么照片上 AVIF 胜过 WebP
AVIF 相对 WebP 的压缩优势源自底层的编解码格式。WebP 用的是 帧内引擎，本为视频设计，自 2010 年起被用于静态图。AVIF 背后的 现代格式 于 2018 年发布，此前数年的研究正是针对 与 的局限。现代格式 施加更激进的色度子采样、细至 4 乘 4 像素的块划分，以及更高效的熵编码器。经大型照片测试集上的 分析验证，实际结果是在照片上、相同感知质量下，AVIF 通常比 WebP 小 20 到 30 个百分点。在颜色平坦、边缘锐利的计算机生成图形上差距收窄，因为 WebP 较简单的算法能高效处理那类样式。对任何最重资产是照片的页面，AVIF 升级都有可量化的带宽影响。
第二次有损处理的实际表现
当你把 WebP 转成 AVIF 时，源和输出都是有损的。WebP 在最初生成时就已决定丢弃哪些颜色信息，这些决定是无法撤销的，转成 AVIF 也找不回一星半点。随后 AVIF 会对它收到的像素数据，在质量 85 下做出自己的取舍。对照片而言，两次有损处理叠加后在常规显示尺寸下仍视觉接近无损，在真实照片内容上约测得。对已被其 WebP 保存劣化的图形，第二次处理可能在其上叠加可见伪影。实用法则是：若源 WebP 在你要展示的尺寸下看着干净，AVIF 也会干净。若 WebP 本就带有压缩噪声，那就在发布前仔细检查 AVIF。
alpha 通道如何走完全程
WebP 与 AVIF 都把透明放在与颜色数据并列的独立 alpha 平面里。转换读取 WebP 的 alpha 通道，在完全透明下合成它，再交给 AVIF，由后者用 现代格式 帧内编码在质量 85 下写出自己的 alpha 轨。柔和的透明渐变、羽化的边缘和半透明区域全都能走完这趟来回。AVIF 的 alpha 平面本身在质量 85 下是有损的，在极端放大时可能在硬边缘上带来几乎看不见的镶边。在网页常规显示尺寸下，与源的差异并不可见。对小图标上要求 alpha 边缘精确的像素级工作，保留 WebP 源，并在发布前以满级放大核对输出。
各浏览器与设备上的保存耗时预期
AVIF 每个浏览器会话预热一次，给第一次转换增加约一秒。在那之后，Chromium 给出最佳吞吐：0.12 百万像素缩略图约 40 毫秒，1 百万像素照片 250 毫秒，4K 照片 2.8 秒，最坏情形下完整 4800 万像素图片 25 秒。Firefox 是显眼的例外，同样的处理约慢四倍，使 4K 情形接近 31 秒，大文件超过两分钟。WebKit 居于两者之间，更靠近 Chromium。各引擎上移动硬件都比桌面慢 3 到 5 倍。对逐个文件的日常转换，笔记本或台式机上的 Chrome 是实用之选。对带大图的 Firefox 用户，坦白的建议是换浏览器或留用 WebP。
Core Web Vitals 与 AVIF 升级
提供照片的页面，为每张加载的图片都付出带宽代价。如果那些图片现在是 WebP，把它们转成 AVIF 会在照片上把每张的传输削减约 20 到 30 个百分点。在一张有 WebP 主图的页面上，AVIF 把它降到约 noticeably smaller。在一个有十二张 WebP 缩略图的产品网格上，AVIF 省下约 noticeably smaller 的总页面重量。当 LCP 元素是图片时，这些节省会直接影响 Largest Contentful Paint。在 AVIF 约 94% 的全球浏览器支持下，一个 AVIF 优先、WebP 在后的 picture 元素几乎覆盖所有流量。标记的代价每个图片组件只付一次，而带宽的节省会在此后每次页面加载里重复兑现。
为什么 AVIF 转换要靠服务器
AVIF 建立在 现代格式 编解码之上，和现代视频同属一个家族，为了换来紧凑的文件，它被有意做得很重。把这件事做好，尤其是大照片，在真正的服务器上比在手机浏览器里快得多也稳得多，所以这一对会把图片送到我们的服务器，去生成尽可能好的 AVIF。文件被处理，结果返回给你，下载会在大约 2 小时内移除，没有账户，也不长期保存。一次转换多张图片总是在服务器上进行，它会把做好的一组拼成一个下载，并在同样短的时间里删除。如果连不上我们的服务器，单张转换会改在浏览器里生成，那个文件留在本地，为了方便接受更慢的生成。交换很清楚：服务器在最需要的格式上买来质量和速度，而你的文件绝不会被保留得超过转换所需的短暂窗口。