JPEG 转 AVIF
把 JPEG 文件拖到下方，即可得到 AVIF 文件。转换在你自己的设备上完成，因此不会上传，除了浏览器内存上限之外没有任何大小或数量限制。
把图片拖到这里
Ctrl/⌘ V粘贴截图或复制的图片
支持 JPEG
数值越低文件越小。照片用 75 通常就够。
100% 本地处理 文件不会被上传。
为什么要把 JPEG 转成 AVIF？
同一张图片，AVIF 的体积通常明显小于原始的 JPEG。当你在压缩页面体积、或者要挤进某个上传大小限制时，这一点很关键。
AVIF 支持透明通道，所以转换之后你可以再抠掉背景。但转换本身并不会凭空造出 JPEG 文件里原本就没有的透明区域。
两种格式都是有损的。每一次重新编码都会再丢掉一点细节，所以最好从原图开始转，而不是从一张已经反复转过几轮的副本开始。
这是网页图片优化里比较激进的一端。在观感相当的前提下，AVIF 通常能把 JPEG 砍掉一半 —— 收益比 WebP 更大，在图片密集的页面上会直接反映到加载时间里。代价是真实存在的，但范围很窄，在重新编码整个图库之前值得先了解。
转换之前
编码很慢，而这正是格式在干活
AVIF 建立在 AV1 之上，那是一个会努力搜索冗余的视频编解码器。压缩率正是来自那次搜索，而搜索要花时间 —— 一张大图在浏览器里可能要几秒，而 JPEG 只要几毫秒。批量处理时这个成本会累积。它是在构建时付一次，换来每一次页面访问都省下的字节，通常这笔交易划算。
二次编码的问题在这里同样存在
这张 JPEG 已经丢过一次细节，而 AVIF 现在压缩的是剩下的部分，连同那些痕迹一起。从相机原片或母版导出直接编码，得到的 AVIF 会比经由 JPEG 更小也更干净。而且和 WebP 一样，忍住别为了补偿而拉高质量 —— 高设置会让 AVIF 花字节忠实复现 JPEG 的块状痕迹，而那是你最不该保留的东西。
兜底再留一阵子
浏览器支持不错 —— 所有当前的主流浏览器都能读 AVIF —— 但它比 WebP 晚了好几年，老设备、应用内浏览器和邮件客户端构成的长尾也相应更长。用 picture 元素配上 JPEG 或 WebP 兜底，这个问题就不再重要了。
会保留下来的
- 像素尺寸
- 合理设置下的视觉观感
- 大约一半的文件体积
过不来的
- 又一点细节 —— 第二次有损压缩
- 编码速度
- 老设备与邮件客户端的支持
JPEG 与 AVIF 对比一览
| 属性 | JPEG | AVIF |
|---|---|---|
| 压缩方式 | 有损 | 有损 |
| 透明通道 | 不支持 | 支持 |
| 典型文件大小 | 约为同等 JPEG 的 100% | 约为同等 JPEG 的 40-55% |
| 兼容性 | 几乎所有软件都能打开，包括很老的程序 | 所有现代浏览器支持；部分老旧桌面软件尚未跟进 |
| 常见来源 | 数码相机与照片分享 | 为减小页面体积而优化的网站 |
常见问题
我的 JPEG 文件会被上传到哪里吗？
不会。解码器和编码器是运行在本页面内的 WebAssembly 模块。首次使用某种格式时，网络面板可能会显示编解码器下载，但没有任何请求会包含你的文件。在支持离线缓存的浏览器中，用过一次的编解码器会被缓存，之后同类转换可以断网完成。
有文件大小或数量限制吗？
我们不设任何限制。实际上限取决于你设备的内存，因为转换过程中图片需要以未压缩形式驻留内存。在普通笔记本上，一亿像素以内的图片通常都能顺利转换。
转成 AVIF 会损失画质吗？
AVIF 是有损格式，会丢弃部分数据。在默认质量下，正常观看尺寸几乎看不出差别。如果你需要像素级完全一致的副本，请改选 PNG。
手机上能用吗？
可以。同样的 WebAssembly 模块在移动浏览器上也能运行。由于手机 CPU 较弱，转换会比桌面端慢，超大图片也更容易触及内存上限。
从 JPEG 转出去会不会又掉一次画质？
如果目标也是有损格式，会再掉一点。你手上的 JPEG 本身已经丢弃过数据，第二次有损编码会再丢一些。质量设在 80 以上时，这第二次损失很难看出来——但这正是应该保留原图、而不是反复来回转换同一个文件的原因。
AVIF 到底在哪些地方能用？
所有主流浏览器都能原生解码 AVIF，因此用在网页上是安全的。桌面软件则落后不少，很多看图和修图软件仍然打不开它。此外它的编码速度明显慢于这里的其他格式，大图需要等上几秒。