使用方法
- 点「1. 选择本地 JPG 图片」，挑一张
.jpg/.jpeg。结果区随后显示这张图的真实尺寸与原 JPEG 体积，两个数都来自文件本身，不做任何估算。 - 「2. 原图 JPEG 质量估计」只在没有选图时起作用，用来在基准曲线上估算「这个质量档的原图转成 PNG 大概多大」，默认 0.92。选了图之后一律以实测为准。
- 点「转换并下载 PNG」。浏览器把图片解码成 24 位像素，再用
canvas.toBlob(cb, "image/png")无损编码，最后直接触发下载，文件名形如converted-1920x1080.png。 - 看结果区的两块数字：原 JPEG 体积和PNG 体积，以及两者相除的倍数。JPG转PNG 之后体积变大是格式决定的，不是转换出错。
- 点「导出 CSV」把下面的对照表存成带 BOM 的表格，或点「复制对照表」复制成制表符分隔文本，粘进你自己的工作表。
JPG转PNG 能解决什么问题
一是需要无损再编辑。JPEG 每保存一次就重新做一遍 DCT 量化，反复裁剪、标注、贴图会让损失一层层叠加；PNG 保存的是像素本身，存多少次都是同一份字节，编辑过程不再掉画质。所以真正的工作流是「JPG 转 PNG → 在 PNG 上反复改 → 定稿后如果必须交 JPEG 再转回去」。
二是为后续补透明通道留出空间。JPEG 格式根本没有 alpha 平面，一张 JPG 里不存在任何透明信息。转成 PNG 后画布有了 alpha 通道，你可以在此基础上抠背、做圆角、加投影而不必再经历一次有损编码。
三是喂给只吃 PNG 的处理流程。部分 OCR、排版、图标打包、自动化脚本只接受 PNG 输入，这时转格式是流程要求，与体积无关。
四是需要反复保存的中间件。截图、拼图、做对比图这类会存很多遍的临时素材，用 PNG 做中间格式可以保证每一步都不掉画质，最后再决定要不要压成 JPEG。
本页不做这些事：不提高画质（已经丢掉的信息找不回来）、不缩小体积（PNG 一定比同内容的 JPEG 大）、不改尺寸、不加水印、不做批量。它只回答一件事——把这张 JPG 无损装箱成 PNG 之后，像素没变、体积变了多少。
原理：无损容器为什么装不住有损数据
PNG 是无损格式，但「无损」指的是相对它自己的输入像素而言。PNG 由 W3C 收录在 ISO/IEC 15948 里（IETF 侧是 RFC 2083），像素先经过规范定义的 5 种行滤波（None、Sub、Up、Average、Paeth），编码器逐行挑选「滤波后字节绝对值和最小」的那一种，再交给 DEFLATE（RFC 1951，装在 zlib 容器里即 RFC 1950）。整条链路只做可逆变换，所以解出来的像素与压缩前逐位相同。问题是：JPEG 交出来的像素本身就已经不是原始画面了。
损失在 JPEG 那一步就已经发生。JPEG 基线流程由 ITU-T T.81（等价 ISO/IEC 10918-1）规定：RGB 先转 YCbCr，色度按 4:2:0 抽样（Cb、Cr 各缩到一半宽高），画面切成 8×8 块做二维 DCT-II，系数再除以标准量化表并四舍五入。以 1920×1080 为例，共 240 × 135 = 32,400 个亮度块加两张色度各 120 × 68 = 8,160 块。质量参数换算成缩放系数 scale = Q < 50 ? 5000 ÷ Q : 200 − 2 × Q，默认 0.92 对应 scale = 16：亮度 DC 基准值 16 被压到 3，最低频 AC 基准值 11 压到 2，最高频那格 99 压到 16。「除以量化步长再取整」这一步不可逆，被抹掉的细节就永远没了。
转成 PNG 只是把这份损失原样封存。浏览器先解码 JPEG（反量化、反 DCT、色度 2×2 上采样、YCbCr 转 RGB、按 8 位截断），拿到一份 24 位位图；PNG 编码器再对这份位图做无损压缩。实测同一张 1920×1080 基准图：原始像素的 PNG 是 2,720,340 字节，而把质量 0.92 的 JPEG 解码出来再存 PNG 是 2,829,491 字节，两者只差 4.01%——差的那一点正是 JPEG 留下的块效应与色度误差。用 PSNR 衡量，质量 0.92 的 JPEG 相对原图只有 39.05 dB，说明像素早已被改动过，PNG 再无损也救不回来。
体积为什么必然涨。JPEG 存的是稀疏的 DCT 系数再上 Huffman 熵编码，信息密度本来就高；PNG 存的是逐像素值再上 DEFLATE，而照片的像素本身接近噪声，DEFLATE 对这种数据几乎压不动，结果逼近每像素 3 字节的上限。1920×1080 未压缩的 RGB 扫描线是 (1920 × 3 + 1) × 1080 = 6,221,880 字节，而质量 0.92 的 JPEG 只有 379,959 字节。两者的差距不是靠 PNG 参数能补回来的。
一个容易被忽略的口径：这里的倍数随源图质量而变。源 JPEG 压得越狠，转成 PNG 之后倍数越大——质量 0.80 约 13.43×，质量 0.50 约 24.60×。但倍数不会一直涨：到了质量 0.20、0.10，解码出来的像素被压得极其平滑，PNG 反倒压得动，倍数回落到 10.13× 和 4.73×。所以「转 PNG 涨几倍」这个问题没有单一答案，必须看源图的压缩档位。
完整示例（数值仅作演示）
下面这组数字来自一张 1920×1080 的合成基准照片，PNG 侧是真实行滤波加 DEFLATE 压缩后的字节数，JPEG 侧是真实 DCT + 量化 + 熵编码算出的字节数。页面打开时的默认条件与之一致：源质量 0.92、尺寸不变。
- 源 JPEG（质量 0.92）约 379,959 字节 ≈ 371.1 KiB，相对原图的 PSNR 是 39.05 dB；
- 同一张图转成 PNG 后约 2,829,491 字节 ≈ 2.70 MiB，体积是原 JPEG 的 7.45 倍；
- 把源质量顶到 1.00，JPEG 涨到约 602,737 字节，转 PNG 后仍是 4.49 倍——「PNG 更大」和源图压得多狠无关；
- 源质量 0.80 时转 PNG 约 13.43 倍，源质量 0.50 时约 24.60 倍，压缩越狠膨胀越夸张；
- 原始像素直接存 PNG 是 2,720,340 字节，与「解码后再存 PNG」的 2,829,491 字节只差 4.01%，这就是「无损容器装着有损数据」的直接体现；
- 换成 3840×2160 同条件实测：JPEG 约 1,514,801 字节，转 PNG 约 11,279,075 字节，倍数仍是 7.45 倍，说明这个比例基本与分辨率无关。
反过来验证「PNG 无损、JPEG 有损」：同一份像素用 PNG 编码两次，输出是 2,720,340 与 2,720,340 字节，逐字节一致；而 JPEG 在同一质量下反复解码再编码，第一代就到 39.05 dB，之后稳定在 39.04 dB（同质量重编码会收敛），但只要中途换过一次质量档，损失就会叠加——链 0.92→0.70→0.92 末代只剩 35.20 dB，比单档 0.70 的 35.45 dB 还低。
源 JPEG 质量与转 PNG 后体积对照表
下表固定 1920×1080 基准图，逐档改变源 JPEG 的质量，量出「原 JPEG 体积」「解码后 PSNR」和「转成 PNG 后的体积」。「体积倍数」是最后一列，也是决定这次 JPG转PNG 值不值得的关键数字。
| 源 JPEG 质量 | JPEG 体积 | 解码后 PSNR | 转 PNG 后体积 | 体积倍数 |
|---|---|---|---|---|
| 0.10 | 11,929 B | 29.44 dB | 56,449 B | 4.73× |
| 0.20 | 19,765 B | 31.52 dB | 200,198 B | 10.13× |
| 0.30 | 34,079 B | 32.85 dB | 630,934 B | 18.51× |
| 0.40 | 52,085 B | 33.70 dB | 1,231,514 B | 23.64× |
| 0.50 | 73,191 B | 34.26 dB | 1,800,721 B | 24.60× |
| 0.60 | 97,297 B | 34.76 dB | 2,195,512 B | 22.57× |
| 0.70 | 133,911 B | 35.45 dB | 2,369,105 B | 17.69× |
| 0.80 | 186,763 B | 36.13 dB | 2,507,315 B | 13.43× |
| 0.90 | 329,303 B | 38.01 dB | 2,766,679 B | 8.40× |
| 0.92 | 379,959 B | 39.05 dB | 2,829,491 B | 7.45× |
| 0.95 | 495,422 B | 42.24 dB | 2,833,351 B | 5.72× |
| 1.00 | 602,737 B | 54.88 dB | 2,706,349 B | 4.49× |
点「加载更多行」补上换分辨率的几档；它们会告诉你一个结论——同样质量下，1280×720、2560×1440、3840×2160 的膨胀倍数都稳定在 7.45 倍左右，所以选图前不必先算分辨率，直接看质量档就够了。
输入范围、边界与精度说明
- 尺寸上限是硬约束。canvas 单边最大 65535 像素，总面积上限 2²⁸ = 268,435,456 像素（约 16384×16384）。越界时浏览器不抛异常，只会给你一张空白图，所以本页在选图后先做面积校验再编码。
- PNG 输出恒为 8 位。
canvas.toBlob("image/png")出来的都是 8 位通道（RGB 或 RGBA），不会产生 16 位 PNG；JPEG 基线本来就只吃 8 位样本，所以从 JPG 转过来的图不会因为这一步丢位深。 - alpha 通道会补齐，但默认全不透明。JPG 没有透明信息，转出的 PNG 虽然带 alpha 通道，透明值一律是 255。想要真正的透明区，得在 PNG 上再去背景。
- 输出不含 EXIF。canvas 输出的是纯像素位图，相机的型号、镜头、光圈、快门、拍摄时间和 GPS 都不会带过去；原图的方向标记也一并消失（方向已在解码阶段应用到画面上，画面本身是正的）。
- 色度已经被 4:2:0 抽过样。解码时 Cb、Cr 会被 2×2 上采样补回原尺寸，色度的原始数据只有亮度的四分之一，色块边缘的色差损失在转 PNG 之前就存在了。
- 颜色按 sRGB 解释。原图若带 Display P3 等宽色域标记，转换后按 sRGB 解释会显得略淡，需要专业色彩流程请用桌面软件。
- 本页只换格式，不改尺寸。输出像素与原图一致；想边转边缩，请先用图片尺寸调整工具改像素再回到本页。
常见问题
转成 PNG 之后画质会变好吗？
不会。PNG 是无损容器，它只能原样保存你交给它的像素；而 JPG 里的像素早在 DCT 量化那一步就被改过了，信息已经丢了。实测质量 0.92 的 JPEG 相对原图只有 39.05 dB，转成 PNG 后这份误差一分不少地留在文件里。想真正提高画质，只能回到原始拍摄素材重新导出。
为什么体积反而变大了这么多？
因为两个格式存的东西根本不同。JPEG 存的是稀疏的 DCT 系数，信息密度高；PNG 存的是逐像素值，照片像素接近噪声，DEFLATE 几乎压不动。1920×1080 质量 0.92 的实测是 371.1 KiB 涨到 2.70 MiB，约 7.45 倍，这个倍数由格式决定，不是转换出错。
什么情况下 JPG转PNG 才值得做？
三种情况值得：一是这张图还要反复编辑保存很多次，PNG 能保证过程无损；二是后续要在这张图上做透明或半透明处理，需要 alpha 通道；三是下游流程或工具只吃 PNG。除此之外，如果只是想上传、分享、存档，保留原 JPEG 更划算。
转出来的 PNG 能再转回 JPG 吗？会掉画质吗？
能转，但会再掉一次画质。PNG 转 JPEG 要重新做一遍 DCT 量化，等于在已经损失过的像素上再损失一次。所以如果要走「JPG 转 PNG 编辑、最后交 JPEG」的流程，建议全程保留 PNG 副本，只在最后一步输出 JPEG 一次。
为什么滑块上的质量值不一定是原图真实的压缩质量？
JPEG 文件里的量化表虽然能反推质量，但不同软件用的缩放公式不一致，同一张图在线检测出的「质量」也可能差几档。所以这个滑块只是让你在基准曲线上估个范围，选了图之后一切以实测字节数为准。
图片会上传到服务器吗？
不会。文件通过 File 对象在本地解码，像素处理与 PNG 编码都在你的浏览器里用 canvas 完成，导出走 toBlob。想自己确认，打开开发者工具的网络面板，选一张图再点转换，全程不会有任何新请求。
PNG 会存很多次都掉画质吗？
不会。同一份像素用 PNG 编码两次，输出是逐字节一致的（实测两次都是 2,720,340 字节），因为它只做可逆变换。JPEG 则不同：同质量反复保存会收敛到某个电平，但一旦中途改过质量档或做过编辑，损失就叠加，链 0.92→0.70→0.92 的末代 PSNR 会掉到 35.20 dB。
一次能转多张吗？
不能。本页刻意做成一次一张：JPG转PNG 会让体积涨好几倍，逐张确认体积和用途更稳妥；批量转换适合放在桌面端处理，或者送到图片格式转换工具里做多格式矩阵。
相关工具
- WebP转PNG转换器：同样是「出站到 PNG」，但源格式是 WebP，透明通道的处理方式不一样。
- SVG转PNG：矢量转位图，按指定像素栅格化，和本页的像素装箱完全不同。
- 图片裁剪：只切画面不改格式，适合转换前先去边角。
- 图片尺寸调整：想边转边缩先在这里改像素，回到本页再装箱成 PNG。
- 图片压缩工具：体积才是你的硬指标时用它，而不是转成体积更大的 PNG。
- PNG转ICO转换器：以 PNG 为输入做站标的多尺寸图标，和本页方向一致但出口不同。
- 图片工具：查看全部图片工具。