WebP 转 JPG — 在线批量把 WebP 图片转成通用 JPG，兼容打印、邮件与旧系统，本地处理不上传
WebP 转 JPG 补的是兼容性这一课：WebP 在网页上又小又清楚，可一旦离开浏览器就常常碰壁。打印店的排版软件、老版本 Office、只收 JPG 的报名系统、部分邮件客户端和看图工具，见到 .webp 往往直接报错或一片空白。这里在浏览器里把 WebP 完整解码，再用质量滑块重新编码成 JPG，数值越高细节越完整、文件也越大，放在零点八五上下通常比较平衡。JPG 没有透明通道，遇到带透明区域的图标或抠图可以挑一个填充色，初始为白色，免得边缘发黑。支持一次拖入多张，批量列表逐张显示状态与体积，预览区用上一个、下一个切换并排对比，确认后单张下载或整批打包 ZIP。目标格式下拉随时能改成 PNG，已解码的图片会自动重新导出，不必重传。解码走浏览器原生能力，全程不上传，断网也能用；转换后会重新生成一份干净的文件，EXIF 里的拍摄时间、机型和定位不会自动带过去。动图 WebP 只取第一帧，批量列表里还能单独重试或只挑几张下载。
导入图片
目标格式
两种格式共用同一份解码结果，切换后会自动重新导出，不用重新导入图片。
JPG 兼容性最好、体积最小，适合微信、邮件、打印和旧系统；不支持透明背景。
数值越高细节越完整、文件越大。照片建议放在 0.85 上下，截图可以再调高一点。
JPG 没有透明通道，透明和半透明区域会被填成这个颜色，初始为白色，可换成任意颜色。
少数 WebP 带方向标记或取自竖拍素材，解码后横着显示时用这里手动校正。
留空即用原文件名，导出时自动换成对应的扩展名。
预览与导出
批量列表
0 / 0 已完成还没有导入图片。
操作说明
- 把 .webp 图片拖进导入区，或点选择图片一次挑多张；按 Ctrl+V 也能粘贴截图。工具按文件头识别真实格式，扩展名写错不影响判断。
- 目标格式保持 JPG，先把质量放在零点八五上下看一眼体积，再左右微调：照片压得太狠天空会起色块，文字截图则要留意笔画是否发虚。
- 如果原图带透明区域，在填充色里挑一个底色；极少数 WebP 带方向标记，解码后横着显示时用额外旋转校正。
- 用预览区的上一个、下一个逐张并排核对左右两边，确认后下载当前，或在批量列表里逐张下载、打包 ZIP。想换格式直接改下拉，已解码的图片会自动重新导出。
常见问题解答
为什么 WebP 图片在有些软件里打不开？
WebP 是二〇一〇年才发布的格式，浏览器里的支持花了近十年才铺齐，而不少桌面软件、旧版 Office、打印排版系统、内容管理后台和上传表单至今只实现了 JPG、PNG 的读取。文件本身没有损坏，只是对面那套程序还没有 WebP 解码器。转成 JPG 不依赖系统装了什么，拷到哪台电脑都能直接打开，交给打印店或上传到报名系统也最省事。
转成 JPG 会不会再掉一次画质？
会，但通常看不出来。有损 WebP 本身已经压缩过一次，解码成像素再按 JPG 的量化表重新编码属于第二次有损，天空渐变和高反差边缘最容易出现轻微色块或振铃。质量放在零点八五以上，正常尺寸查看基本无感；想让后面的编辑不再继续损失细节，请改用 PNG 那一页，它把解码后的像素无损保存下来，不过也要明白它无法把第一次压缩丢掉的信息变回来。
透明背景会变成什么颜色？
JPG 没有透明通道，透明和半透明区域必须合成到某个底色上，初始为白色，也可以在填充色里换成任意颜色。如果原图是抠好的产品图或带圆角标志，建议选和最终页面一致的颜色，否则贴到深色背景上会出现一圈白边。想保留透明请切换到 PNG，它支持完整的 alpha 通道。
动图 WebP 转出来还会动吗？
不会。浏览器把动画 WebP 交给 canvas 时只提供第一帧，重新编码得到的 JPG 也只支持单帧静态图，所以转换结果是一张静帧。如果动效本身很重要，请保留原始 WebP 或改用专门的动图工具；这一页的定位是把素材落回最通用、最容易被各方接受的静态格式。
图片会被上传到服务器吗？
不会。解码、方向校正、质量调整和编码都在浏览器里完成，WebP 由浏览器原生解出像素，图片数据不离开设备，页面也没有上传接口。首次打开后断网仍可继续转换。这也意味着关掉页面后列表不会保留，重要的原图请自己留好备份；转换生成的是一份全新文件，EXIF 里的拍摄信息不会自动带过去。
概念
WebP 和 JPG 的差异不在谁更清楚，而在设计目标。WebP 是谷歌基于 VP8 视频关键帧做出来的图片格式，用 RIFF 容器装数据，同一份规范里同时提供有损编码、独立的无损编码、alpha 透明通道和动画；有损模式靠帧内预测先猜出一块像素再只记残差，所以同等观感下常比 JPG 小三成。JPG 则是一九九二年定下的老标准，把画面切成八乘八的小块做离散余弦变换，再按量化表把高频系数压掉，普遍还用四比二比零色度抽样把颜色分辨率减半。转 JPG 时浏览器先把 WebP 解成完整像素，再走一遍分块、变换和量化，这是不可逆的二次有损：原图已经丢掉的细节不会回来，天空渐变和高反差边缘最容易出色块或振铃。质量滑块控制的就是量化表，调到一时细节最多但文件明显变大。带 alpha 的 WebP 会先按所选底色合成，因为 JPG 根本没有透明度这一维度；容器里的 EXIF、ICC 和动画帧也不会自动跟过去，多帧 WebP 只取第一帧。工具按文件头识别真实格式，扩展名写错不影响判断。
历史与由来
把时间线摊开，会看到两个相差近二十年的格式在同一台设备上碰头。JPG 这一头更早：一九九二年 JPEG 标准由 ISO 与 ITU 联合发布，用离散余弦变换加量化表把照片压到几十 KB，一九九四年前后 JFIF 普及，几乎所有软件都认它，此后三十年主体没大变，代价是八位色深、不支持透明、高压缩下容易出现方块。另一头从二〇一〇年九月开始：前一年谷歌收购视频编码公司 On2 Technologies，拿到 VP8，随后以它的帧内编码为蓝本发布 WebP，用 RIFF 容器装图像数据。首版只有有损模式，二〇一一年补上 alpha 通道扩展，二〇一二年前后加入独立的无损编码、元数据与动画，libwebp 一路开源，被 Chromium、Android 和大量服务端工具链采用。接下来是漫长的推广：Chrome 很早支持，火狐到二〇一九年才跟上，Safari 直到二〇二〇年才补齐，中间那些年 picture 标签与服务端按请求头协商几乎是标配，一套页面要维护两份素材。有意思的是，WebP 铺开之后，麻烦反而从网页内部转到外部：设计软件、旧版 Office、打印流程、内容管理系统和上传表单长期只认 JPG 或 PNG，站点目录里越来越多的 .webp 离开浏览器后寸步难行。真正的解法不需要新算法：canvas 的 toBlob 早就接受 image/jpeg 与质量参数，编码端毫无障碍；浏览器一旦能原生解出 WebP 像素，本地解码加本地重编码就成了最稳妥的组合，连上传接口都不必存在。后来 AVIF 借 AV1 帧内编码又把压缩率推了一截，JPEG XL 也在标准化里兜过一圈，可新格式越多，这种把素材落回通用格式的需求就越不会消失。今天点一下就能转换，看似省掉的只是一次上传，实质是把一段本该留在本地的计算还给了本地。
相关关键词
纠错反馈
如果发现工具问题或有任何建议，欢迎通过邮箱联系我们，我们会认真查看每一条反馈。
