做游戏素材最常被体积卡住：小游戏包体 4MB 上限、网页首屏要快、图集塞不进手机显存。而 PNG 对带噪点的图、渐变图、AI 出的图几乎是「原样存」——一张 1200×800 的场景图随随便便 2MB 起步。这一页把整批图重新编码成 WebP（也支持 AVIF / JPEG），并把话说清楚：每张图原始多大、压完多大、省了百分之多少、画质到底差了多少，全都是实测数字，不是一句「已优化」。更实用的是「按目标体积」模式——你只要写「这张必须压进 200KB」，工具会二分搜索出还能用的最高质量档。全程在浏览器本地处理，图片不上传服务器。
批量拖入 · WebP / AVIF / JPEG · 按质量或按目标体积 · 限制最大边长 · 逐张差异度实测 · 并排对比 · 导出 ZIP / 单张
PNG / JPG / WebP，一次可以选很多张
有。用页面里的示例三张图（1200×800 噪点场景 / 900×600 UI 面板 / 640×640 带透明道具）实测，质量 75：
| 图 | 原 PNG | WebP q75 | 省了 | 差异度 |
|---|---|---|---|---|
| 噪点场景 1200×800 | 1.66 MB | 255 KB | 85% | 0.16 |
| UI 面板 900×600 | 21.5 KB | 5.5 KB | 74% | 0.29 |
| 带透明道具 640×640 | 80.7 KB | 8.1 KB | 90% | 0.36 |
| 合计 | 1.76 MB | 268 KB | 85% | — |
关键是：差异度全部落在「肉眼看不出」区间，而体积掉了一大半。PNG 对噪点和渐变几乎无能为力（它只擅长大面积纯色），WebP 恰恰是为此设计的。
差异度是实测出来的，不是估的：把原始图和压缩后解码回来的图都缩到 64×64，逐像素比 RGB 偏差，按透明通道加权后取平均每通道偏差百分比。低于 0.8 = 肉眼看不出；0.8~2.5 = 放大看边缘才有一点差别；超过 2.5 = 差异明显，建议把质量调回去。这个数字让你不用一张张放大去看，直接看数就行。
默认 75 是通用甜点：绝大多数图在这个档位省得最多、肉眼无损。要更保险选 85；只是缩略图、占位图可以降到 60。别为了省几 KB 一路拉到 30——那点体积不如改尺寸来得划算（见下一条）。
因为浏览器（Chrome / Edge）在 quality 为 1.0 时会切到无损 WebP 编码，它并不是「有损的最高质量档」。所以体积在 99 → 100 之间会突然变小、不连续：实测一张规则色块图，q0.99 要 11.6 KB，q1.0 只要 3.0 KB——无损编码器对纯色、规则图形极擅长，而有损编码器为了「保住每个色块的精确颜色」反而要花更多字节。这是好事不是 bug：想要无损就拉到 100，别停在 99。代价是无损编码慢一些，图越大越明显（这也是「按目标体积」模式对超大图跳过无损试探的原因）。
填一个每 KB 数（比如 200），工具会对每张图二分搜索质量档：先试最高档，塞不下就往下二分，最终返回「还塞得下的最高质量」——不是第一个碰运气碰到的。如果连最低质量都塞不下，它会如实告诉你没达标（列表里质量列会停在 q1）。这时候正确的做法是去改尺寸，而不是继续压质量。
因为这两个手段的代价完全不同。把质量从 75 拉到 40，省下的体积是拿画质换的（色块、边缘振铃都出来了）；而把一张在屏幕上只显示 300px 宽的图从 2048 降到 1024，肉眼完全看不出，体积直接掉到四分之一。素材类图片八成都存在「存得比用得大得多」的问题，所以先把最长边拉下来，往往比狠压质量既小又好看。
默认都选 WebP：它支持透明、同画质下比 JPEG 小、现在游戏引擎和浏览器基本都认。只有必须兼容很老的环境才用 JPEG——注意 JPEG 不认透明通道，这时工具会按你选的颜色给透明区铺底（默认白色），不铺会得到黑块。选 PNG 通常不会变小，它主要是让你确认「原 PNG 到底有多大」。
能救一大截，但要按顺序做：① 先把所有图的最长边拉到实际显示尺寸的 1~2 倍（多数素材能从 2048 降到 1024 甚至 512）；② 再批量转 WebP，质量 75~80；③ 最后对剩下的几张大头用「按目标体积」压到指定 KB。这三步下来，原本 8MB 的素材压进 4MB 很常见。压完记得用「导出 ZIP」一次拿整套。
免费，无水印、无需注册。整个编码过程用的是浏览器自带的 canvas.toBlob，在你自己的浏览器里跑完，图片不经过任何服务器。
