JPG 转 WebP v1.0

JPG 转 WebP，是把一张已经压缩过的照片换成一种编码效率更高的格式，目的很直接：让同一张图在网页上更小、打开更快。DocPivot 的 JPG 转 WebP 工具全程在浏览器里完成，默认质量定在 85，一张常见的手机照片体积平均减少 57%，肉眼看不出差别。多数同类工具把默认值放在 92 到 95 之间，同一张图只能减掉 7% 左右，省下的流量基本可以忽略。差别不在编码器，在于默认值是怎么定的。

默认质量为什么定在 85

因为源文件本来就是有损的。JPEG 在拍摄或导出的那一刻已经丢掉了一部分细节，留在画面里的除了内容，还有块效应、振铃这些上一轮压缩的痕迹。质量值拉到 95，编码器并不区分哪些是照片、哪些是杂讯，它会把码率老老实实花在复刻这些杂讯上，结果就是文件几乎没小多少。85 这个数字是实测出来的，不是沿用行业习惯。

同一张 1200 万像素照片，四档设置下的实测结果如下：

PSNR 从 45.2 dB 掉到 41.9 dB，数字上像是明显下滑，实际把两张图放到 100% 缩放下逐块比对，也很难指出哪里不一样，而体积差了将近一半。真正会看出问题的是最后一档：压到小 73% 之后，天空、皮肤这类平缓渐变的区域开始出现色带。所以默认值卡在质量下降停止被看见的位置，而不是停止存在的位置。如果只是想让现有的 JPG 变小、不换格式，用图片压缩工具会更省事。

一张 JPG 进来之后发生了什么

整条流程分五步，每一步都在你的设备上跑完，没有任何一步需要联网。

1. 按方向标记解码。读取 JPEG 的 EXIF Orientation 并在解码时直接摆正，横着拍的手机照片进来是躺着的，出去是立着的。这一步不能省，因为 WebP 格式里没有方向标记这个字段，问题没法往下传。
2. 交给 libwebp 编码。用编译成 wasm 的 libwebp，开启 sharp YUV 选项。这个选项对文字边缘、产品轮廓这类硬边界有实测提升，色度采样时不容易糊边。
3. 或者按体积反推质量。填了体积上限就走这条路，在质量 5 到 95 之间最多做 8 次真实编码，取能塞进上限的最高质量。
4. 需要的话缩边。三个选项：保持原尺寸、长边 2048 px、长边 1200 px，都是只缩不放，源图本来就小于目标值时原样输出。
5. 输出结果。单张保留原文件名，多张打包成 ZIP。结果卡片写明新尺寸、新体积和节省比例，一次最多处理 30 张。

换成其他格式的入口也在同一套流程上，只是解码那一步换了模块：PNG 转 WebP 工具处理带透明通道的素材，HEIC 转 WebP 工具直接吃苹果设备拍的原片，高分辨率扫描图和印刷素材则走TIFF 转 WebP 工具。编码和输出环节是同一套，行为一致。

把图压进 200 KB，靠搜索而不是靠猜

体积上限是 DocPivot 区别于绝大多数在线转换器的功能。做外贸独立站的人对这类要求不陌生：首屏 banner 控制在 100 KB 上下，内页配图 50 KB 以内，这是很多建站教程写死的经验值。问题在于，同样一个质量值放在不同复杂度的图片上，出来的体积能差好几倍——一张纯色背景的产品图和一张枝叶密布的实景图，质量 80 的结果完全不是一个量级。

所以填了“保持在多少 KB 以内”之后，工具不去猜一个固定质量，而是拿二分搜索在 5 到 95 之间试，每次都是真实编码后称重，最多 8 次收敛。整批图片复杂度参差不齐时，每张各自落在自己合适的质量上，而不是被一个统一数值一刀切。如果体积仍然下不来，通常是分辨率太大而不是质量太高，先用图片尺寸调整工具把长边收一收，效果比继续压质量明显得多。一张 4000 px 宽的原片放进最宽 1200 px 的内容区，多出来的像素只是在浪费带宽，缩边省下的体积比降质量省下的多得多，而且不牺牲观感。

手机拍的照片转完不会躺倒

竖着拿手机拍的照片，传感器实际记录的往往是横向画面，正确方向写在 EXIF 的 Orientation 字段里，看图软件读到这个字段才把画面转正。很多在线转换工具解码时忽略这个字段，于是 JPG 在电脑上看着好好的，转成 WebP 传到网站上就躺倒了。

DocPivot 在解码阶段就把旋转应用到像素上，输出的 WebP 无论用什么程序打开都是正的。想确认原图里到底记了什么方向、什么设备、什么时间，可以先用EXIF 信息查看工具看一眼再决定要不要转。苹果手机拍的 HEIC 原片同样把方向写在 EXIF 里，先用HEIC 转 JPG 工具落地成 JPG 再转，方向一样不会出错。

文件不出本机，以及随之而来的两件事

转换在浏览器内完成，图片不上传、不排队、不受每日次数限制。国内同类站点普遍写着“文件 1 小时后自动删除”，这句话的前提是文件已经上传到了对方服务器——删除承诺解决的是保存时长问题，不是传输本身。《个人信息保护法》和《数据安全法》对个人信息的对外提供有明确要求，文件从头到尾没有离开本机，也就不存在这一层。

第二件事是元数据。JPEG 里常带着拍摄时间、设备型号，以及开了定位的手机写入的 GPS 坐标，后者在国内法律语境下属于敏感个人信息中的行踪轨迹。转换成 WebP 时这些字段不会被带过去，等于顺手做了一次清理。如果原始 JPG 本身也要对外发，那还是得单独处理，用照片元数据清除工具把字段抹掉再发出去。

什么场景下值得把 JPG 换成 WebP

判断标准只有一条：这张图最终是在网页或 App 里被浏览器解码的，那就值得换；如果它要被人下载、被别的软件打开、被平台后台接收，就要先确认对方认不认 WebP。

• 外贸独立站与 WordPress 站点：图片通常是 LCP 元素，直接决定 Core Web Vitals 里最难达标的那一项。整站图片换成 WebP 是成本最低的一次性优化。
• 跨境电商详情页：详情页动辄十几张长图，体积减半意味着移动端首屏等待时间和跳出率一起下降。
• CDN 流量成本：图片占带宽的大头，按流量计费的站点这一项省下的是真金白银，一个月能看出差额。
• 小程序与 App 内嵌页：自有服务器托管的图片资源，只要客户端解码环境可控，用 WebP 没有额外成本。
• 邮件营销与落地页：落地页配图先过一遍转换再上线，配合图片裁剪工具把构图收紧，体积还能再降一截。
• 图库归档预览：原片留 JPG，预览图用 WebP，缩略图墙的加载速度差别很直观。

反过来，需要发给客户、上传到平台后台、或者交给设计师继续加工的图，转 WebP 反而添麻烦。批量素材整理时用图片格式转换工具先理清楚哪些要转、哪些保持原样，比转完再往回倒省事。

这个工具做不到的事

有必要把限制写清楚，因为这类页面上写“无损压缩”的太多了。

• 这是有损转有损。JPEG 已经扔掉过一轮细节，WebP 再扔掉一点，两轮损失叠加。默认值只是把第二轮控制在看不见的范围内，不是让它不发生。任何声称 JPG 转 WebP“无损”的说法，在源文件是 JPEG 的前提下都不成立。
• “原始”这一档不等于无损。它是质量 100，在照片上跑出来的文件通常比你手里的 JPG 还大 32%。真正的无损 WebP 只在源文件本身无损时才有意义，比如从 PNG 出发的场景。
• EXIF 和 GPS 不会带进 WebP。对隐私是好事，对需要保留拍摄参数的摄影归档是坏事，这种情况请保留原始 JPG。
• 老环境仍然打不开 WebP。Windows 7 上的旧版看图程序、部分国产办公软件、以及一些设计工具的老版本都不认这个格式。收到 WebP 打不开的人可以用WebP 转 JPG 工具转回去，需要保留透明底的话改用WebP 转 PNG 工具。
• 微信公众号后台不收 WebP。素材上传只认 JPG、PNG、GIF，公众号文章里那些 WebP 图片是微信服务器自己转的，不是运营者传上去的。给公众号准备配图请直接用 JPG。

与上传型转换服务的实测差异

拿同一张 1200 万像素照片跑 CloudConvert 做对照，差距主要出在默认值和运行位置上。

同一张图输出小 43%，来源不是编码器更好，两边用的都是 libwebp，差别全在默认质量的选法上。批量场景下这个差距会被放大：30 张图跑完一遍，省下的总量足够让整个图片目录换个量级。想再往下压，可以试试JPG 转 AVIF 工具，同等观感下 AVIF 通常还能再小一些，代价是老设备的兼容性差一截。

需要说明的是，DocPivot 不做“转换速度更快”这类宣传。本机转换的速度取决于你的设备，一台老笔记本处理 30 张 2400 万像素照片，未必比服务器端快。它换来的是文件不出本机、没有排队、没有额度，以及一个按实测定下来的默认值。

常见问题