WebP 图片怎么保存成 PNG？三种路径与画质取舍
从网页上保存图片，存下来的十有六七是 .webp：Google 图片搜索、维基百科、大部分电商详情页、WordPress 站的缩略图，早就换成了 WebP。体积小、加载快，对站点是好事。
麻烦出现在「拿到文件之后」。老版本 Photoshop 打不开、公司 OA 的上传框只认 jpg/png、印刷厂要 300dpi 的 PNG、PPT 里贴进去显示成一个空白框——于是就有了这个问题：WebP 图片怎么保存成 PNG。这篇不堆工具链接，先把三件事讲透：右键另存到底有没有真的转格式、改扩展名为什么一定无效、透明背景转完为什么发灰，再给三条路径的取舍和验收办法。
一、WebP 已经普及，为什么还要退回 PNG
WebP 的卖点只有一个：压缩率。同样的视觉效果，有损 WebP 比 JPEG 小 25%~35%，无损 WebP 比 PNG 小约 26%。代价是兼容性和可编辑性——它本质是一张「给浏览器看的成品图」，不是「给软件改的素材」。
PNG 正好相反。1996 年的格式，压缩率一般，但从系统预览、Office、到印刷流程、到几乎每门语言的图像库都原生支持，而且它是真正的无损压缩加完整 alpha 通道。所以「退回 PNG」不是技术退步，而是把成品图还原成可加工的半成品。想清楚这一点，后面选路径就不会纠结。
还有一个常见误会要先排除：有人以为转成 PNG 能顺便把文件变小。方向正好相反，同内容下 PNG 一定更大。要压体积请走缩放与压缩那条线，别拿转格式当压缩用。
二、先分清你要的是哪一种 PNG
同样一句「转成 PNG」，背后的需求差得很远，处理方式也不一样。先对号入座：
- 要透明背景：logo、抠好的商品图、UI 图标、贴纸。这类只能是 PNG 或保持 WebP，绝不能碰 JPG——JPEG 从标准层面就没有 alpha 通道，透明区会被填成纯色。
- 要无损编辑：还要继续裁剪、调色、反复保存、交给别人改。PNG 存的是像素本身，多次保存不掉画质；有损 WebP 每存一次都在重新量化。
- 只是对方不收 WebP：上传表单报「文件类型不支持」、邮件客户端预览不出来、某个老系统读不了。这种情况对画质没要求，能打开就算过关。
需求定了，路径选择就变成一道减法题：只求能打开，用最快的；要保透明，必须确认输出带 alpha；要控参数、要重跑，才值得上命令行。
三、三条路径对比：先看代价，再选工具
把三条常见路径摆在一起，差别不在「能不能转」，而在会不会真的转、透明保不保、批量顶不顶得住。
| 路径 | 适用场景 | 代价与坑 |
|---|---|---|
| 浏览器右键「图片另存为」 | 临时救急、单张、图片就在当前页面、手边只有浏览器 | 多数浏览器保存的是服务器返回的原始字节，后缀仍是 .webp，格式根本没变；走「复制图像 → 粘贴到画图/预览 → 另存为」才是真转码，但只能一张张来，动图只拿到当前帧 |
| 系统自带（画图 / 预览 / 照片） | 单张到十几张、不想装软件、文件敏感不愿上传 | 完全离线、可信、透明通道能保住；但批量要靠 PowerShell 或「快捷指令」，导出对话框里还有「质量」这类对 PNG 无效的干扰项 |
| 转换工具（在线 / 桌面 / 命令行） | 几十张以上、要固定参数、要可重复执行 | 在线工具零安装但要上传文件，有隐私和体积限制，部分还默认开启调色板压缩；命令行要装 libwebp 或 ImageMagick，但最稳、最适合批量 |
一句话结论：单张走系统工具，批量走命令行，在线工具只用来试参数。凡是涉及证件、合同、客户原图的，别上传。
四、三条路径的分步操作
路径一：浏览器右键另存，先确认它到底存了什么
这一步最容易被误解。右键「图片另存为」时，浏览器拿到的是服务器发来的字节流，它不会替你换编码器，所以存下来通常还是一份 WebP，只是你的系统隐藏了扩展名，看起来像「一张图」而已。
- 右键图片 → 「图片另存为」，把「所有文件」类型的显示打开，看默认后缀。是 .webp 就说明格式没变。
- 真正有效的是走剪贴板：右键「复制图像」，打开 Windows 画图或 macOS 预览，新建后粘贴，再「另存为 PNG」。剪贴板里传的是解码后的位图，这一步才是真转码。
- 验证：Windows 资源管理器开「详细信息」看「类型」列，macOS 按 Cmd+I 看「格式」一栏，写 PNG 才算成功。
为什么不用截图代替？截图会按屏幕显示尺寸重采样，还会被缩放比例和色彩管理影响，1:1 看就糊了。剪贴板粘贴保留原始像素，前提是粘贴前别缩放页面、别开阅读模式。另外，动态 WebP 走这条路只会拿到当前显示的那一帧。
路径二：系统自带工具，最稳但最慢
Windows 用画图打开 .webp（Win10 1903 之后原生支持），文件 → 另存为 → PNG。macOS 用预览打开，文件 → 导出，格式选 PNG，需要透明就确认 alpha 没被去掉。
两个容易踩的点：一是别用「导出为 JPEG 再改名」，那会永久丢掉透明通道，也永久丢掉一次画质；二是导出面板里的「质量」滑块对 PNG 无效——PNG 是无损的，能调的只有色彩位深和是否带 alpha，调「质量」只是心理安慰。
要批量，系统方案也能凑：macOS 建一个「快捷指令」，动作是「更改图像类型」→ PNG，把整个文件夹拖进去即可；Windows 可以用 PowerShell 调用 System.Drawing 逐张另存。都比命令行麻烦，但胜在不装任何第三方软件。
路径三：转换工具与命令行
单张、偶尔一次，在线转换够用；但只要超过二十张，命令行的时间优势立刻显现，而且参数是确定的，下次还能一模一样地重跑。
libwebp 自带的 dwebp 就是专门干这个的，解码后直接写 PNG：
dwebp in.webp -o out.png
整目录批量，保留原文件名只换后缀：
for f in *.webp; do dwebp "$f" -o "${f%.webp}.png"; done
机器上装了 ImageMagick 的话，一条命令处理一个目录（注意它默认只取动画 WebP 的第一帧）：
magick mogrify -format png *.webp
顺手提一句 ffmpeg，你机器上本来就有它的话同样能用：ffmpeg -i in.webp out.png。
命令行里最容易出的事故是输出写回同一目录同名，脚本跑第二遍就会互相覆盖。养成习惯：原图放 src/，输出放 out/，命令里显式指定输出目录。
五、画质与体积：能保住什么，保不住什么
先把预期摆正：转格式只能搬运像素，不能创造细节。源 WebP 如果是有损压缩的（绝大多数网页图都是有损），丢掉的高频信息已经没了，包进 PNG 也不会回来。你得到的是一个「以后不再继续掉画质」的起点，不是一个「变清晰」的结果。
- 无损 WebP → PNG：逐像素一致，除了体积变大，画质零损失。这是唯一配得上「无损转换」四个字的情况。
- 有损 WebP → PNG：像素原样搬运，但源图的压缩痕迹（色块、蚊状纹）也一起搬了过来，甚至因为不再有后续压缩掩盖而更显眼。
- 透明通道：PNG 完整支持半透明，前提是输出别选 PNG-8 调色板模式，也别在中途转成 JPG。
- 色彩位深：WebP 只有 8 位/通道，所以转出来的 PNG 最多也是 8 位。选 16 位只是把数据写宽，不会凭空多出信息，体积倒是直接翻倍。
体积要有心理准备，这不是工具出错：一张 5000×2813 的 WebP 若为 1.45MB，全彩 PNG 可能到 11MB，接近八倍；而带透明通道的切图通常只涨 1.5 倍左右，因为 PNG 本来就是为这类图设计的。原因是编码思路完全不同——WebP 用块预测加有损量化，PNG 用逐行滤波加 DEFLATE，一个在丢信息换体积，一个在死守像素。
想压体积，有三个正当手段，别用「转成 JPG」糊弄：一是把颜色数降到 256 色以内（PNG-8），平面图、截图、图标几乎看不出差别，体积能掉六到七成；二是先缩尺寸再转，像素少一半，体积掉约四分之三；三是转完过一遍 PNG 优化器（oxipng、pngquant 之类），只重排压缩流，不动像素。
透明背景转完为什么发灰
这是搜索量很高的一类困惑，按顺序排查，四种原因占了绝大多数：
- 其实转成了 JPG。JPG 没有 alpha，透明区被合成到白底或黑底上，看着就是一块脏灰。看扩展名，更要看文件头。
- 用了 PNG-8 调色板。调色板模式下 alpha 只剩 1 位（全透明或不透明），原本柔和的半透明边缘被硬切成锯齿，边缘残留一圈灰边。
- 那是查看器的棋盘格。很多看图软件用灰白格子表示透明，那是背景不是图内容。放到深色底上看一眼就能分辨。
- 缩放时对透明像素采样。把带透明的图缩小，边缘会混入透明区的 RGB（常见是黑色），于是出现暗边。正确做法是在预乘 alpha 的状态下缩放，或先扩边再缩放。
还有一种更隐蔽的：源 WebP 里嵌了 ICC 配置文件，转换工具没保留，浏览器按 sRGB 解释，整张图偏灰偏淡。转换后用取色器在同一坐标比一下 RGB，偏差超过 2~3 就要怀疑色彩管理断链，具体检查项可以对照sRGB 与 AdobeRGB 怎么选里的导出部分。
六、批量转换与命名
几十张以上就别手工点了。批量的难点从来不在转换本身，而在转完之后找不回对应关系。下面四条是实践下来最省返工的规则：
- 命名：保留原名只换后缀最不容易出错（
IMG_0421.webp → IMG_0421.png）。需要区分时加固定后缀_png，别在文件名里加日期——日期会把同一批图的自然排序打乱。 - 目录：原图进
src/，输出进out/，脚本只读 src 只写 out。跑错了重跑一遍就行，不会产生「转换的转换」。 - 重名：a.webp 和 a.png 同时存在时，Windows 不冲突，但在大小写敏感的系统或网盘同步时会互相覆盖，转换前先扫一遍同名文件。
- 留档：超过 50 张时，把命令和参数写进一个 txt 跟图放在一起。三个月后要重做，那行命令比重装一遍工具省事得多。
既要改尺寸又要改格式时，顺序是先缩放再转码，一次重采样到位；转完再缩，等于对一个已经变大的 PNG 重新插值，既白占磁盘又白掉一次画质。如果你本来就在纠结源图该不该用 WebP，图片转 WebP 值不值里有实测的体积对照。
七、验收清单
转完别只看「能打开」。下面六条一起过一遍，能挡掉九成返工：
- 文件头对不对：
file *.png的输出里应含PNG image data；只改了扩展名的会显示成 Web/P image。 - 尺寸一致：宽高与源图逐像素相同；做过缩放的，要确认落到的是你要的目标尺寸。
- 透明还在：放到深色背景上看边缘，没有白边也没有黑边。
- 颜色没漂：同一坐标取色，RGB 偏差在个位数以内；带 ICC 的图确认配置文件跟着过来了。
- 体积可接受：照片涨 5~9 倍、切图涨 1~2 倍属正常，涨 20 倍以上要查是不是输出成了 16 位。
- 数量对得上：输出文件数等于输入文件数，没有 0 字节的失败产物。
常见问题
浏览器右键「图片另存为」，存下来的就是 PNG 吗？
多数情况下不是。Chromium 内核的浏览器保存的是服务器返回的原始字节，后缀通常还跟着 .webp，只是系统隐藏了扩展名。判断办法只有两个：看文件头，或者改走「复制图像 → 粘贴到画图/预览 → 另存为 PNG」，剪贴板里传的是解码后的位图，那一步才是真正的转码。
直接把 .webp 改成 .png 为什么打不开？
因为扩展名只是文件名的一部分，不参与解码。软件和服务器都是读文件开头几个字节判断格式：PNG 开头是 89 50 4E 47，WebP 是 RIFF 打头、偏移 8 处写着 WEBP。改名之后内容还是 WebP，解码器照旧按 WebP 解，碰上只认 PNG 的程序就报错或显示空白。少数只查后缀的上传框能蒙过去，但后续处理几乎一定失败。
转换成 PNG 之后文件大了一倍多，是工具出问题了吗？
不是，这是格式差异。PNG 逐像素无损保存，WebP 是预测编码加有损量化，压缩率不在一个量级。照片类涨 5~9 倍很常见，带透明通道的切图通常只涨 1.5 倍左右。要压体积就降颜色数、缩尺寸，或者过一遍 PNG 优化器，别指望换格式能瘦身。
转成 PNG 能让模糊的图变清楚吗？
不能。转格式只搬运已有像素，不生成新细节。有损 WebP 里丢掉的纹理已经不存在了，装进无损容器也不会回来。转 PNG 的真实收益是「从这一步起不再继续掉画质」，方便后面反复编辑和交付。
动态 WebP 转 PNG 会怎样？
只会得到第一帧静态图。PNG 本身是单帧格式，要保留动画得用 APNG 或者继续用 WebP；如果你只想要其中某一帧，优先找支持指定帧号的工具，比先转再看更准。
一张图转了三次，画质会掉吗？
PNG 到 PNG 不会掉，无损格式每次保存都只是重排压缩流。真正会掉的是「PNG → JPG → PNG」这种来回穿有损格式的路径，每穿一次就重新量化一次。所以中间过程统一留在 PNG 或无损 WebP 里，只有最终交付才导出有损格式。
小结
WebP 转 PNG 的技术本质只有一句话：用解码器读出像素，再用 PNG 编码器写出去。难的是三个认知点——右键另存多半没转格式、改扩展名一定无效、转完文件变大是正常现象。
路径按数量选：一两张走系统自带或剪贴板，几十张走命令行，敏感文件一律别上传。画质上别抱幻想，有损源转不出无损细节；体积上提前算好预算，带透明的图别用调色板。更多格式之间的取舍与损耗对照，见格式转换栏目和图片格式对比：按用途选格式。