图片格式转换_PNG/JPEG/WebP 批量互转

文件	原始格式与体积	输出格式	转换后体积	变化	下载
尚未转换任何图片。选好图片与输出格式后点「开始转换」，每张的结果会依次列在这里。

使用方法

点「选择图片」，在弹出的窗口里按住 Ctrl（macOS 按 Command）或 Shift 一次选中多张，做批量处理。可读入的源格式包括 PNG、JPEG、WebP、AVIF、GIF 与 BMP——能读不等于能写，这一点下面会讲清楚。
在「输出格式」里选目标。默认是 WebP，因为它在照片上通常比 JPEG 小 25%～35%，同时保留透明通道，兼容率也到了 97%。
「输出质量」默认 0.8，允许 0.1～1，每 0.05 一档。这个参数只对 JPEG 和 WebP 的有损模式生效；输出 PNG 时会被编码器直接忽略，PNG 永远是无损的。
如果输出格式选了 JPEG，先看一眼「JPEG 底色」。JPEG 没有透明通道，源图里的透明区域在编码时会被丢弃，多数实现会留下黑块，所以本页会先用这个颜色铺满整张画布再画图，默认 #ffffff（白）。深色页面用的图记得改成对应的背景色。
点「开始转换」（或在任一输入框里按 Enter）。每张图转完就追加一行到结果表里，含转换前后的格式、体积、变化百分比和一条下载链接。点「下载全部」会把表格里已有的结果依次下载下来。

这个图片格式转换工具能解决什么问题

一是把一批图统一成同一个格式。设计稿导出时 PNG、JPEG 混着来，上传前要统一成 WebP，逐张改名另存很费时间；这里选一次输出格式，整批走完。

二是在「体积」和「兼容性」之间做一次可量化的取舍。同一个格式对不同内容的效果差别很大：照片换成 WebP 通常能小 25%～35%，而一张纯色图标换成 WebP 可能几乎不变甚至略大。结果表里的「变化」一栏就是用来告诉你这次转换到底赚了还是亏了，而不是让你凭感觉相信「新格式一定更小」。

三是把「浏览器悄悄换了格式」这件事暴露出来。向 canvas.toBlob 要一个它编不出来的 MIME 时，规范之外的实际行为是静默回退成 PNG——不抛异常、不返回 null、不打警告。结果是文件名写着 .webp、字节却是 PNG。本页每张转换完都会检查返回的 blob.type 是否等于目标格式，不一致就在「变化」列标成「回退」，避免你把一个假扩展名传上服务器。

四是透明与白底的显式处理。透明 PNG 直接转 JPEG 会出现黑底，这是最常见的转换事故；把它做成一个可选的底色输入框，比事后解释要直观。

本页不做这些事：不做选区与尺寸变换，不批量调亮度或加滤镜，也不做服务端转码。它只处理「换容器」，一次一张地在本地编解码。

原理：canvas.toBlob 与四种格式的角色分工

一次图片格式转换只调用一个 API：canvas.toBlob(callback, mimeType, quality)。浏览器把画布里的原始像素缓冲交给内置编码器，编好后以 Blob 交回。编码器就是浏览器厂商内置的 libjpeg、libwebp 这一层，不引入任何外部脚本，所以不同浏览器在同一个 quality 下产生的字节数会有细微差别，这是正常的。

输入经过的中转站是 RGBA 缓冲。源文件先被浏览器解码成每通道 8 位的 RGBA 像素，画到画布上，再重新编码。这张中间缓冲的大小只跟像素数有关，跟源文件多大无关：一张 1920×1080 的图，中间量固定是 2073600 × 4 = 8294400 字节（7.91 MiB）；如果源文件是 400 KiB 的 JPEG，缓冲反而比它大 20 倍。这就是为什么批量转换时吃内存的是「图片的像素数」，而不是「文件体积」。

四种格式的角色并不对等。PNG 由 RFC 2083 定义，只做无损，用 DEFLATE 压缩，所以能完整保留每个像素与 alpha 通道，代价是照片类内容体积常常是 JPEG 的 120%～200%。JPEG 由 ISO/IEC 10918-1（等价于 ITU-T T.81）定义，只有有损模式、没有 alpha 通道，色度固定 4:2:0 二次采样。WebP 是 Google 基于 VP8 的 RIFF 容器格式，同一套编码器同时提供有损与无损两种模式，并支持 alpha，照片上典型比 JPEG 小 25%～35%。AVIF 的容器来自 ISO/IEC 23008-12（HEIF），编码器是 AOMedia 的 AV1，压缩效率比 JPEG 高 40%～55%、比 WebP 再高约 28.6%，还多了 10～12 位色深与 HDR，代价是编码慢、生态新。

兼容率差在哪里。按 caniuse 的 2026 年 4 月全局口径：PNG 与 JPEG 都是 100%，WebP 约 97%（缺口 3 个百分点，按全球网民量级约 1.7 亿人），AVIF 约 95%（缺口 5 个百分点，约 2.8 亿人）。首次可用版本也差了六年：WebP 从 Chrome 32（2014）就有，AVIF 要等到 Chrome 85（2020）、Firefox 93（2021）、Safari 16.4（2023）。这两个数字之间的关系很实际——每多要一个百分点的新格式优势，就要多准备一层回退图。

能读不等于能写。浏览器的解码器与编码器是两条独立发布的代码路径。按 Playwright 1.61 在三个引擎上的实测：Chromium 149 只能编码 PNG、JPEG、WebP；Firefox 151 多一个 BMP；WebKit 26.5 能编码 PNG、JPEG、AVIF、BMP、GIF、HEIC，却偏偏不能编码 WebP。所以「我的浏览器能显示 AVIF」推不出「我的浏览器能输出 AVIF」——在 Chromium 里请求 image/avif，实际拿回来的是 image/png。回退的代价很实在：向 WebKit 请求 WebP 得到的 PNG 有 7993002 字节，是 Chromium 同图 WebP 的 19.8 倍。

完整示例（一张 1920×1080 照片走完全部方向）

下面用一张照片把图片格式转换的每个方向走一遍。取一张 1920×1080 的照片，原始 JPEG 体积设为 400 KiB（quality 0.8 附近的常见值），此时每像素比特数是 400 × 1024 × 8 ÷ 2073600 = 1.58 bit/px。以此为基准，其他格式的典型体积是：

转到 WebP（有损，0.8）：约 280 KiB，比 JPEG 小 30%，省下约 120 KiB；
转到 AVIF（有损）：约 200 KiB，比 JPEG 小 50%，比 WebP 再小 28.6%——但 Chromium 里编不出来，本页会把它标成「回退」；
转到 PNG（无损）：约 480～800 KiB，是 JPEG 的 120%～200%，因为无损要老老实实存下每个像素；
保持 JPEG 再转一次 JPEG：体积可能略有下降，但这是「有损压有损」，画质只会变差不会变好。

把这个结论放大到批量场景：1000 张 400 KiB 的照片，保持 JPEG 是 390.6 MiB；全部转成 WebP 是 273.4 MiB，省下 117.2 MiB；如果编码器支持、全部转成 AVIF 则是 195.3 MiB，省下 195.3 MiB。省下的这部分就是 CDN 流量的直接成本。

再看质量档位的影响（同一张图、同一个 JPEG 编码器）：quality 0.5 约 180 KiB、0.6 约 232 KiB、0.7 约 288 KiB、0.8 约 400 KiB、0.92 约 620 KiB、1.0 约 920 KiB。从 0.8 提到 1.0 体积翻了一倍多，肉眼看却几乎没有区别——所以默认给的是 0.8，而不是「越高越好」。

输入范围与互转对照表

下表是四种格式两两之间的可行性，横轴是目标格式。带「不可输出」的方向指的是：浏览器能解码、但 canvas.toBlob 编不出来，必须借服务端或 WASM 编码器，本页不做。

源格式 ↓ / 目标 →	PNG	JPEG	WebP	AVIF
PNG	可转。无损重编，体积通常不会变小	可转。透明被底色替代，照片类可缩到约 1/3	可转。透明保留，有损时比 JPEG 再小 25%～35%	可解码，但浏览器 canvas 不能编码
JPEG	可转。有损数据装进无损容器，体积涨到 120%～200%	可转但无意义。二次有损，画质只降不升	推荐方向。小 25%～35%，兼容率 97%	体积最小方向（小 40%～55%），但浏览器不能编码
WebP	可转。进无损容器后体积明显变大	可转。会丢掉透明通道，需要先铺底色	可转。同格式重编，体积基本持平	可解码，但浏览器 canvas 不能编码
AVIF	可转。体积显著变大，仅在必须兼容老环境时用	可转。会丢掉透明通道	推荐方向。体积略增但兼容率从 95% 提到 97%	可解码，但浏览器 canvas 不能编码

下表把四种格式的特性与兼容率并排放，方便你按用途选：

格式	透明	有损模式	无损模式	最大色深	全局兼容率	首次可用版本
PNG	支持	不支持	支持	8 位	100%	所有浏览器
JPEG	不支持	支持	不支持	8 位	100%	所有浏览器
WebP	支持	支持	支持	8 位	约 97%	Chrome 32 / Firefox 65 / Safari 14
AVIF	支持	支持	支持	12 位	约 95%	Chrome 85 / Firefox 93 / Safari 16.4

选择建议只有三句：要在邮件、打印或老系统里打开，用 JPEG 或 PNG，它们 100% 通用；要放到自己的网站上、能控制 <picture> 回退链，首选 AVIF、回退 WebP、兜底 JPEG；要保住透明又要体积小，用 WebP 的无损或有损模式，而不是 PNG。

输出格式选择、边界与精度说明

输出质量 0.1～1，步长 0.05，默认 0.8。低于 0.5 时平滑渐变区会出现明显块状伪影，只适合做缩略图或低带宽兜底；0.8 提到 1.0 体积涨一倍多、肉眼却分不出来。输入小数、越界值或空值都会被拒绝，并提示具体范围。
PNG 重编不保证变小。PNG 本身已经做过 DEFLATE 压缩，解到画布再编回去，压缩器拿到的输入与原来不同，体积可能变大也可能略小。想要确定变小，应该走 WebP 无损或专门的优化器，而不是「PNG 转 PNG」。
JPEG 没有 alpha。RGBA 缓冲里的 alpha 在编码 JPEG 时被丢弃，透明像素的 RGB 值通常接近黑色。本页在画图之前先用底色填满画布，所以不会出现黑块，但你必须在转换前想好用什么底色。
元数据会丢。经过画布重编码后，EXIF 拍摄信息、GPS 坐标、ICC 色彩配置、方向标记都不再写入输出文件。ICC 不完整时浏览器会按 sRGB 处理，颜色可能与专业软件的显示略有出入。
只保留第一帧。GIF 与动图 WebP 走 canvas 这条路只会画出第一帧，输出的是静态图。要保留动画，需要专门的动图工具。
画布大小有硬上限。Chromium 的画布边长上限是 16384（2¹⁴），即 268435456 像素；iOS Safari 单张画布的面积上限约为 4096 × 4096 = 16777216 像素。超过上限的图会得到空白结果或直接失败，这时要先做尺寸变换再转格式。
编码格式按实测探测，不按浏览器名字猜。用户代理字符串里同时含有 Chrome 与 Safari 的标识，用它判断编码能力在两个方向上都会出错。本页在页面加载时用一块 4×4 的小画布对四种 MIME 各试编一次，把结果缓存下来，并把下拉框里探测失败的目标格式直接移除，再从结果里算一句「本浏览器可输出 N 种格式」。
体积变化会受内容影响。照片适合有损、图标与截图适合无损，这是经验而不是定律。同一批文件里出现「变大」的行是正常的，看结果表的「变化」列比看格式名字可靠。

常见问题

为什么选不了 AVIF 作为输出格式？

因为大多数浏览器的画布编码器根本不支持 AVIF。AVIF 的解码从 Chrome 85、Firefox 93、Safari 16.4 起就有了，但编码是另一条路径：Chromium 只能编 PNG、JPEG、WebP。页面加载时会实测一次，探测失败就把这个选项从下拉框里移除。要产出 AVIF，需要在服务端用 libavif、sharp 这类工具，或者在页面里挂一个编译成 WASM 的 AV1 编码器——两者都超出了本页「纯本地、不引外部库」的范围。

转完之后文件反而变大了，是出 Bug 了吗？

不是，这是内容决定的。有损编码对小尺寸、纯色、边缘锐利的图（图标、截屏、二维码）收益很小，甚至因为容器头开销而略增；无损编码则一定会把 JPEG 这类有损数据「还原成没丢过」的样子，体积涨到 120%～200% 很正常。看结果表的「变化」列，变大了就别用这个方向。

透明 PNG 转 JPEG 之后背景变黑怎么办？

把「JPEG 底色」改成你实际要用的背景色（例如深色页面填 #0f172a），再重新转一次。原因是 JPEG 格式压根没有 alpha 通道，透明处必须由某个不透明颜色顶上，如果直接编码，多数实现会把未定义区域按黑色写出。本页的做法是先铺满底色再画图，所以底色选什么，输出就是什么。

上传的图片会被存到服务器吗？

不会。解码、画布重绘、编码三步全部发生在当前页面里，没有任何网络请求，也没有把文件写进浏览器存储。想自己验证，打开开发者工具的 Network 面板，一边转图一边观察，除了页面本身的资源不会有别的请求发出。需要保密的设计稿、身份证照片这类文件在本页处理是安全的。

批量转 200 张图，页面卡住正常吗？

正常，而且是单线程跑的。每张图都要完整解码成 RGBA 缓冲再重编，一张 20 兆像素的照片中间缓冲就是 80 MB 左右，连续处理会让内存占用明显上升、主线程被占满，界面短暂无响应。建议分批处理，一次 20～50 张；超大图先做尺寸变换再转格式。

「下载」按钮拿到的文件扩展名对吗？

对的，扩展名由实际输出的 MIME 推导：PNG 写 .png、JPEG 写 .jpg、WebP 写 .webp、AVIF 写 .avif。更重要的是，只有在 blob.type 与目标格式一致时才会给出下载链接；如果编码器发生了静默回退，那一行会显示「回退：实际输出 image/png」，不会让你下载到一个扩展名与内容不符的文件。

做过一次图片格式转换，画质会损失吗？转回来能还原吗？

要看中间经过的是什么。有损转有损（JPEG → WebP、JPEG → JPEG）每转一次就叠一次量化误差，反复转十次会明显糊掉，这类格式应当只转一次。有损转无损（JPEG → PNG）不会让已经丢掉的像素回来，只是把当前状态原样存下，体积还更大，所以不建议拿它当「修复」手段。无损转有损（PNG → WebP 有损）则是一次性的、可控的取舍。

WebP 还是 AVIF，到底该选哪个？

看你的三个约束。第一是受众：兼容率 97% 对 95%，差的 3 与 5 个百分点换算成人数大约是 1.7 亿与 2.8 亿，面向老 iOS 或受管控企业环境时这个差距不能忽略。第二是产出位置：AVIF 编码慢，适合构建期离线产出，不适合用户在线上传后实时转。第三是收益：AVIF 相对 WebP 再小约 28.6%，对图片站值得，对只有几张配图的博客就未必值那套额外管线。稳妥做法是 AVIF 主图 + WebP 回退 + JPEG 兜底，交给 <picture> 自行协商。

图片格式转换