用户上传了一张 iPhone 拍的照片。文件是 HEIC，约 1.8 MB。你的 <img> 标签不能依赖它：HEIC 在 Chrome、Firefox 和 Edge 里都没有原生支持。所以这张图要么变成 3.4 MB 的 JPG，要么变成约 1.2 MB、肉眼无差别的 WebP。正是这个差距，让 WebP 成为 HEIC 格式照片的答案。
本指南覆盖 HEIC 转 WebP、各格式之间的体积对比，以及从浏览器工具到可以塞进构建流程的 shell 命令等一系列选项。
为什么是 WebP 而不是 HEIC
HEIC 在存储照片上很出色，同等质量下大约只有 JPEG 的一半。但作为网页分发格式，它毫无用处。Chrome、Firefox、Edge 和 Safari 多年前就都支持 WebP 了，而 HEIC 只在 Safari 和少数厂商特有场景里受支持。你不能指望 HEIC 来处理用户上传的图片，这正是转换流程存在的原因。
WebP 和 HEIC 覆盖同一片领域：它是建立在现代压缩之上的有损格式，带无损模式和 alpha 透明。对照片来说，同等视觉质量下 WebP 和 JPG 的实际差距是文件小大约 25% 到 35%。在图片密集的页面上，这是实打实的节省。
体积对比
同一张 1200 万像素照片，同等视觉质量：
| 格式 | 体积 | 浏览器支持 | 备注 |
|---|---|---|---|
| HEIC | ~1.8 MB | 仅 Safari | iPhone 的源格式 |
| JPG | ~3.4 MB | 全部 | 基准 |
| WebP | ~1.2 MB | 全部 | 有损，支持 alpha |
| PNG | ~24 MB | 全部 | 无损，不适合照片 |
如果你想了解 WebP 相对 JPG 和 PNG 处于什么位置的背景，网页图片格式指南有完整对比。
方案 1：在浏览器里转换
最简单的路径是完完全全在设备上运行的工具。HEIC 转 WebP 转换器用 WebAssembly 在本地解码 HEIC 并写出 WebP 文件，照片永远不会离开你的机器。你可以设置质量、转换整个文件夹、把结果下载成 ZIP。这适合一次性转换，也适合不习惯命令行的设计师或编辑。
方案 2：在命令行转换
对处理流程来说，经典组合是 libheif 加 libwebp。在 macOS 上用 Homebrew：
brew install libheif webp
然后用 heif-convert 和 cwebp 转换：
heif-convert input.heic output.png
cwebp -q 82 output.png -o output.webp
或者用 ffmpeg 跳过中间文件：
ffmpeg -i input.heic -c:v libwebp -quality 82 output.webp
两条命令都支持质量参数，cwebp 的控制项最全，包括无损模式和用 -m 6 追求最慢、最小的输出。处理文件夹就写个循环：
for f in *.heic; do heif-convert "$f" "${f%.heic}.png"; cwebp -q 82 "${f%.heic}.png" -o "${f%.heic}.webp"; done
这足以接进一个 shell 脚本或 CI 任务，在服务端处理上传。
在 WebP 里选择质量和格式
有两个决定对输出的影响超过其他一切：
- 有损 vs 无损。
cwebp -lossless或带无损标志的-q 100保留每一个像素，但文件更大。用于截图、logo，以及任何带纯色和文字的内容。照片用有损。 - 质量数值。
-q 82是照片的合理默认值：肉眼干净，比 JPG 小得多。追求高质量时，-q 90花费更多字节，但更接近源文件。这和 JPG 质量设置的取舍一样，HEIC 转 JPG 不损失画质有详细说明。
WebP 也能处理 alpha，所以带透明通道的 HEIC 图像能顺利走完这一程，而 JPG 会把它丢掉。
关于更新格式的一点说明
AVIF 是 AV1 基础上的继任者，体积上通常胜过 WebP，现在所有主流浏览器都支持它。如果你在搭一套全新的流程，并且可以自选解码器，那么针对你的具体图片，AVIF 值得和 WebP 放在一起测一测。代价是编码器速度和工具成熟度，这也是 WebP 至今仍是大多数团队安全默认值的原因。网页图片格式指南对各格式的定位有更多说明。
结论
凡是最终要放到网站上的东西，都从 HEIC 转成 WebP。它到处受支持，同等质量下比 JPG 方案更小，用浏览器工具或两条命令的 shell 流程就能转换。把原始 HEIC 当作真相来源，在上传时或批量任务里转换，让格式替你算加载时间的账。