在浏览器中运行

图片转 WebP

在浏览器里把 JPG、PNG 等转成 WebP。批量处理，带实时体积读数 —— 或者直接写出你需要的 KB 数，让它自己找画质。

本地处理0 上传约 1.2 秒无需账号

一次最多 50 张

整个文件夹拖进来。本地跑的同类工具，多数一次只能处理一张。

压到指定体积

要压到 150 KB 以内？填上数字，画质自动帮你调好。

五种输入格式

JPG、PNG、GIF、BMP、AVIF，可以混在同一批里。

文件不上传

转换在这个标签页里完成，而且我们会先确认你的浏览器真的做得到。

一句话： 这个工具在你的浏览器里把图片转成 WebP，一次最多 50 张，输入可以是 JPG、PNG、GIF、BMP 或 AVIF。你可以拖画质滑块，也可以直接写出目标体积（KB），让二分搜索去找那个刚好塞得下的画质。透明会原样保留。在这一切之前，它会先确认你的浏览器真的能编码 WebP —— 因为有的浏览器不能，而且它们失败时不会吭声。

为什么 WebP 能让页面更快

在同等观感画质下，一张 WebP 通常比对应的 JPEG 小 25% 到 35%，而 WebP 的无损模式比 PNG 小约 26%。这个差距就是「把图片转成 WebP」这件事的全部理由 —— 在网页上，字节就是时间。

图片几乎总是网页下载的东西里最重的那一项，所以网站一慢，第一个该看的就是它。把一张图转成 WebP，是少数几个几乎不费力气、效果又能立刻量出来的优化：同一张图，看上去一样，字节少了三分之一。照片多的页面，把 JPG 转成 WebP 往往就是能拿到的最大一笔。

这件事的意义不止于「别让人等」。Largest Contentful Paint —— Google 用来判断页面多快变得可用的那个指标 —— 常常就由一张主图决定。把那张图变小，你动的就是搜索引擎真正在看的那个数字。

兼容性已经不再是问题

WebP 曾经是那种「大家都留一手」的格式，那个阶段已经过去了：现在所有在用的浏览器都能显示 WebP，看不了的访客占比，已经比关掉 JavaScript 的人还少。fallback 从必须变成了可选。

什么时候不值得

一个 4 KB 的小图标不会小到哪里去，而本来就接近最优的纯色 PNG 转成 WebP 收益也有限。回报集中在照片和大幅装饰图上 —— 而那也正是页面重量所在的地方。

盯的是体积，不是画质数字

画质值是编码器上的一个设定。而你的页面预算，本来就是用体积写的。这个工具让你直接说出后者，由它去算前者 —— 而这恰恰是别的工具留给你自己做的那部分。

每一个为了网站把图转成 WebP 的人，脑子里都有一个数字，而那几乎从来不是画质等级。那是「主图得压到 200 KB 以内」，或者「整个相册加起来不能超过 1 MB」。可几乎所有工具 —— 包括那些在你浏览器里本地跑的 —— 都只递给你一个画质滑块，剩下的算术留给你自己。

切到目标体积，填上你要的 KB 数，转换器就会去搜索仍然塞得下的最高画质：编码八次，每次把范围减半，全部在这个标签页里完成。你拿到的是满足约束的前提下最好看的那个文件，而不是一个还要自己回头去核对的猜测。

这个搜索到底在做什么

它先按最高画质编一遍 —— 如果本来就塞得下，那就一点画质都不用牺牲。否则开始二分：试中点，塞得下就留着并往更高画质试，塞不下就往低了试。八轮能把 5 到 98 的区间收敛到 1 以内，比你肉眼能分辨的差别还细。

目标达不到的时候

一张 4000 像素的照片，任何画质下都塞不进 50 KB，工具会直说，而不是悄悄给你一个没达标的文件。遇到这种情况，答案在分辨率而不在压缩 —— 一张显示在 800 像素位置上的图，携带的像素是需要量的五倍。

一个务实的起步预算

对多数内容型网站来说，主图压到 200 KB 以内、正文配图压到 100 KB 以内，就能让页面在手机网络上跑得舒服。把这个设成目标，整批转成 WebP，你的页面重量就是你选的，而不是继承来的。

该选多高的画质

如果你更想直接设画质，那么真正有用的区间比滑块看上去要窄。大约 60 以下伪影会变得明显；92 以上体积迅速增长，换来的差别几乎没人看得出。

80 到 90 之间是多数网页图片该待的地方。WebP 出名的那件事就发生在这里：一张 85 画质、由 JPG 转来的 WebP，明显比它的源文件小，而看不出让掉了什么。

照片很吃得住

柔和的渐变和传感器噪点能藏住压缩伪影，这正是有损格式当初被设计出来要处理的场景。照片用画质 82，在浏览器会显示的任何尺寸下，都和原图分不出来。

文字和纯色需要更高

截图、图表和任何带字的图，都会在硬边缘周围长出光晕 —— 和 JPEG 是同一种失效方式。这类图把画质保持在 90 以上，或者留作 PNG，让边缘保持精确。

读数才是真正的答案

拖动滑块，工具会对你的第一个文件真的编一遍并报出体积。这里内容比设置更重要：同样的画质，一张照片和一张截图的体积可能相差极大。

不是每个浏览器都造得出 WebP

读 WebP 和写 WebP 是两种不同的能力。现在所有浏览器都能显示 WebP，但 WebKit —— Safari 背后的引擎 —— 至今没有向网页开放编码能力。而当浏览器造不出你要的格式时，它不会报错，它会不声不响地给你一个 PNG。

问题就出在这份沉默上。文件带着你预期的名字、你预期的扩展名，和完全不对的内容抵达。把它传到你的网站上，你就发布了一个披着 WebP 外衣的 PNG：比你起步时的 JPEG 还大，而且一点也不更快。

所以在你添加第一个文件之前，这个工具会先编码一个一像素的 canvas，检查回来的到底是什么。如果结果不是真正的 WebP，页面就把话说清楚然后停下 —— 没有上传区，没有转换按钮。这是个生硬的结局，但它远好过一次悄悄产出一堆看着对、其实不对的文件的转换。

如果你看到了那条提示

用 Chrome、Edge 或 Firefox 打开这个页面就能正常转换。Safari 里没有开关可调，编码器根本就没有暴露出来。如果你在 iPhone 或 iPad 上，注意那里所有浏览器底层都是 WebKit，换浏览器也没用。

为什么别的转换器不提醒你

多数在浏览器里跑的工具，只是调一下编码器然后相信返回的结果。有的还更进一步，把 Safari 列进兼容列表 —— 这对「读 WebP」是对的，对「写 WebP」不是。这个检测只要三行代码；多半只是没人想到去看。

只能有损 —— 以及为什么这通常没关系

WebP 有无损模式，但浏览器不开放它。这个工具产出的全部是有损 WebP，我们宁可直说，也不想让你以为不是。

要产出无损 WebP 需要 libwebp，而在网页里这意味着在用户转换任何东西之前，先给每一位访客下发几百 KB 的 WebAssembly。一个通篇在讲「页面应该更轻」的网站，不该做这种交易。

而实际上你损失得很少。画质 80 到 90 的有损 WebP，本来就是照片的正确选择 —— 那正是这个格式被造出来要处理的情况，无损反而会给你一个大得多的文件，换来一个你看不出的差别。

什么时候你确实需要无损

Logo、图标、图表，以及之后还要缩放或编辑的截图，值得拥有精确的像素。这些用 PNG 仍然是好答案，而且它对纯色本来就压得不错 —— 把 PNG 转成 WebP 换来的收益没有你想的多。如果某个 PNG 比你希望的重，压缩它比转换它更有用。

三步把图片转成 WebP

整个转换都在你自己的机器上完成，没有上传、没有排队、不用等服务器。原始文件不会被改动。

1
添加图片
一次拖入最多 50 个文件 —— JPG、PNG、GIF、BMP 和 AVIF 可以混在同一批里。
2
设定画质，或者目标体积
拖动滑块看着真实输出体积变化，或者切到目标体积，填上你的页面预算允许的 KB 数。这一步决定了 WebP 最终有多重。
3
转换并下载
每个文件都会显示转换前后的体积。可以逐个下载，也可以打包成一个 ZIP。

小提示 — 先缩尺寸再转换。一张显示在 800 像素、却存成 4000 像素的图，携带的数据是需要量的二十五倍，而这一点任何画质设置都救不回来。

说明 — 体积读数是按第一个文件实测的。它是真的编了一遍，不是估算，所以拿它来规划整批是靠得住的。

透明和动画怎么办

透明会带过去

WebP 有 alpha 通道，所以把带透明背景的 PNG 转成 WebP，透明会完整保留。这也是 WebP 在很多工作流里同时取代了 JPEG 和 PNG、而不只是其中之一的原因。

动画不会

WebP 支持动画，但浏览器没法从 canvas 产出一个动画 WebP。拖进来的动画 GIF，出来的是它第一帧的静图。如果你需要动画 WebP，那件事需要专门的编码器，而这里不是。

你的文件从未离开这个标签页

就这一项转换而言，本地处理很常见，本该如此。这个也一样，包括你添加任何文件之前跑的那次编码器检测。

你可以用十秒钟验证：打开页面，关掉 Wi-Fi，再转一个文件。它照样能用，因为本来就没有什么要发出去。

浏览器内转换 vs 上传式转换

就这一项转换而言，本地处理已经不再是区分点，所以下面列的是这些工具真正分道扬镳的地方。

对比项	本工具	其他工具
按 KB 指定目标体积	有，二分搜索	只有上传式工具才有
检测浏览器能否编码	有，开始之前就查	没有 —— 失败时不吭声
批量上限	50 个文件，免费	Squoosh 一次只能一张
输入格式	JPG、PNG、GIF、BMP、AVIF	各家不一
转换在哪里发生	你的浏览器	有本地也有上传
无损 WebP	不支持 —— 见下方说明	服务端工具可以