AVIF 转 JPEG XL
把 AVIF 文件拖到下方，即可得到 JPEG XL 文件。转换在你自己的设备上完成，因此不会上传，除了浏览器内存上限之外没有任何大小或数量限制。
把图片拖到这里
Ctrl/⌘ V粘贴截图或复制的图片
支持 AVIF
数值越低文件越小。照片用 75 通常就够。
100% 本地处理 文件不会被上传。
为什么要把 AVIF 转成 JPEG XL？
两种格式都是有损的。每一次重新编码都会再丢掉一点细节，所以最好从原图开始转，而不是从一张已经反复转过几轮的副本开始。
这是当前存在的两个能力最强的图片格式，在它们之间转换很少是为了能力。AVIF 赢了部署这场比赛，而 JPEG XL 普遍被认为工程上更好。往这个方向走，意味着你更看重技术上领先的那个，而不是你实际能发布的那个。
转换之前
你正在转离浏览器支持的那一个
AVIF 在每个主流浏览器里都默认启用。而 JXL 截至 2026 年 8 月不是 —— 只有 Safari 无需用户干预就能打开它，Chrome 145 把解码器放在 flag 后面，Firefox 放在一个偏好设置后面。对任何要放到网页上的东西，这个方向是反的。它只在做存储时说得通，或者是在提前押注 Chrome 预计 2026 下半年的默认开启。
这个方向的编码快得多
有一个真实的实际优势：JXL 的编码比 AVIF 快不少。AV1 的压缩来自一次昂贵的搜索，一张大图可能要好几秒。如果你在批量处理，而瓶颈是编码时间而不是文件大小，这个差别明显且真实。
损失不大，但收获也不大
透明、高位深和 HDR 两边都支持，所以这个转换不损失特性。但它仍然是一次重新编码：一张有损 AVIF 解码后再编码成有损 JXL，会经历第二代损失，而换来的压缩收益，从一个已压缩的源出发时，其实很有限。除非你确实需要 JXL，否则这一趟往往不值得。
会保留下来的
- 透明通道
- 高位深与 HDR
- 比 AVIF 更快的编码
过不来的
- 浏览器的默认支持
- 一点细节 —— 第二次有损压缩
- 动画，如果源文件有的话
AVIF 与 JPEG XL 对比一览
| 属性 | AVIF | JPEG XL |
|---|---|---|
| 压缩方式 | 有损 | 有损 |
| 透明通道 | 支持 | 支持 |
| 典型文件大小 | 约为同等 JPEG 的 40-55% | 约为同等 JPEG 的 45-60% |
| 兼容性 | 所有现代浏览器支持；部分老旧桌面软件尚未跟进 | Safari 与较新的 Chrome 支持；其他环境仍不普遍 |
| 常见来源 | 为减小页面体积而优化的网站 | 长期归档与摄影后期流程 |
常见问题
我的 AVIF 文件会被上传到哪里吗？
不会。解码器和编码器是运行在本页面内的 WebAssembly 模块。首次使用某种格式时，网络面板可能会显示编解码器下载，但没有任何请求会包含你的文件。在支持离线缓存的浏览器中，用过一次的编解码器会被缓存，之后同类转换可以断网完成。
有文件大小或数量限制吗？
我们不设任何限制。实际上限取决于你设备的内存，因为转换过程中图片需要以未压缩形式驻留内存。在普通笔记本上，一亿像素以内的图片通常都能顺利转换。
转成 JPEG XL 会损失画质吗？
JPEG XL 是有损格式，会丢弃部分数据。在默认质量下，正常观看尺寸几乎看不出差别。如果你需要像素级完全一致的副本，请改选 PNG。
手机上能用吗？
可以。同样的 WebAssembly 模块在移动浏览器上也能运行。由于手机 CPU 较弱，转换会比桌面端慢，超大图片也更容易触及内存上限。
AVIF 文件是从哪来的？
几乎都来自网站。AVIF 的压缩率优于目前广泛使用的其他格式，所以在意页面体积的网站会用它。相机和手机不会生成 AVIF，因此大多数人只有在从网上保存图片时才会碰到它。
JPEG XL 现在能用了吗？
算是能用了一部分。Safari 支持它已有一段时间，Chrome 也在 2026 年初正式支持，但整体覆盖率仍在 15% 左右。它适合用于归档——那种场合下压缩质量比通用性更重要；而对于今天要放上公开网站的图片，它还不是好选择。