PNG与JPG：你应该实际保存哪个？

无损与有损，JPG没有的alpha通道以及模糊文本的色度子采样，两个格式的文件大小测量。

August 9, 2026

PNG和JPG在一个问题上有所不同：文件是否能准确记住每个像素？PNG可以。JPG丢弃人眼难以捕捉的细节，换来更小的文件大小。这个单一的分歧几乎决定了你遇到的每种情况，对于海滩照片是一个方向，而对于电子表格的截图则是另一个方向。

以下每个数字均来自LeanImg自己的工具在浏览器标签页中运行的结果，测试文件为：texture.jpg，3840x2160，538.6 KB，以及alpha.png，900x606，942.4 KB，背景透明。我们构建这些工具时没有API路由和服务器操作，因此文件从未离开你的机器。这个类别的大多数网站会将你的图像上传到服务器，然后承诺一个小时后删除它。这里没有任何需要删除的内容，这就是我们的隐私页面简短的原因。

我应该选择哪个，PNG还是JPG？

照片使用JPG。截图、徽标、图表、线条艺术以及任何需要透明度的内容使用PNG。MDN的格式指南也划定了同样的界限。在智能模式下，我们的压缩器将texture.jpg从538.6 KB压缩到286.1 KB，使用MozJPEG时质量为80，减少了47%。将滑块拖到60，同一照片的大小为212.4 KB。在30时为131 KB，减少了76%。

这个分歧源于每种格式的压缩方式。JPG的设计假设相邻像素相互融合，这适合渐变和胶卷颗粒。截图在每个文本边缘打破了这一假设。PNG根据每个像素的邻居进行预测，然后压缩差异，因此它在用户界面中由相同颜色构成的平坦区域上表现最佳。

无损压缩对文件大小究竟有什么影响？

无损意味着解码后的像素逐位完全相同，这是PNG规范所要求的。这并不意味着文件不能缩小。我们压缩器的PNG模式在级别3下运行oxipng，将alpha.png从942.4 KB压缩到383.9 KB。这是59%的减少，且每个像素值都得以保留。

“更小文件大小”的PNG选项是另一种情况。它运行imagequant，在PNG写入之前将图像减少到一个调色板，alpha.png的大小为98.3 KB。这是90%的减少。无论.png扩展名暗示什么，这都是一个有损结果，因此如果该图像是主副本，请保留原始文件。

为什么JPG会模糊彩色文本和细线？

因为JPG以低于亮度的分辨率存储颜色。该格式将亮度与两个色度通道分开，如ITU-T T.81中所规定，编码器通常会对色度进行下采样，使一个颜色样本覆盖2x2像素块。在像texture.jpg这样的3840x2160照片上你不会察觉到这一点。在一条红色像素线与白色背景的对比中，该线的颜色在应用任何质量设置之前会与三个白色邻居的颜色平均，而没有任何滑块位置能将其恢复。

截图是它影响的地方。切换到WebP并不能避免这个问题，因为WebP的有损模式锁定在4:2:0色度并应用相同的平均。PNG保留每个像素的确切RGB值，这就是为什么UI捕获、二维码和文本叠加应该使用PNG。如果PNG仍然太重，可以量化并保留该格式。

当我保存为JPG时，透明度会发生什么？

它会被填充。JPEG在任何模式下都不携带alpha通道，因此必须有某种东西来决定透明像素后面是什么。我们的PNG到JPG转换器在编码之前将它们合成到白色背景上，而压缩器在目标格式没有alpha时也会这样做。如果没有这一步，它们会变成黑色，因为完全透明的像素通常在下面携带RGB 0,0,0。

你无法逆转这一过程。通过JPG到PNG返回会得到一个PNG，里面有一个白色矩形替代了原本的透明部分，以及第一次传递中烘焙进来的任何JPG伪影。压缩还会剥离每一部分元数据：EXIF、GPS、ICC配置文件和嵌入缩略图都会消失，尽管方向仍然保留。保留PNG主文件；你会需要它。如果你要从照片中剪切一个主题，我们的背景去除工具总是以带alpha的PNG格式写入，正是这个原因，剪切的图像比你放入的JPG重的原因，而且图标生成器默认背景颜色为#ffffff，因此透明的徽标会落在白色方块上，直到你更改该字段。

为什么我的PNG比JPG大得多？

摄影噪声让PNG的预测器无从下手。每一行是根据上方的行进行猜测，剩余的差异被压缩，这在平坦的按钮上表现出色，而在颗粒图像上几乎无用。看看这两个测试文件。alpha.png是900x606，大小为942.4 KB，而texture.jpg是3840x2160，像素数量超过十五倍，大小为538.6 KB。调色板量化是缩小这一差距的杠杆，它将alpha.png压缩到98.3 KB。

我应该保存WebP或AVIF并跳过这个问题吗？

有时，尽管值得测量。我们在所有三种格式中以相同的滑块位置80对texture.jpg进行了压缩，然后在63时再次进行。

在滑块80时，AVIF产生的文件最大，看起来不合常理，原因在于我们自己的代码。对于JPEG源，压缩器将你的滑块乘以它从源的量化表中读取的质量，因此源估计为60时，滑块在80时实际编码为48。WebP和AVIF则直接使用80。在63时，这是AVIF的智能模式默认值，顺序翻转：AVIF为186.9 KB，而WebP为200.6 KB，相对于538.6 KB的源。AVIF每次编码还需10到11秒，而JPEG和WebP则瞬时完成，在你决定之前值得检查一下浏览器支持。我们在关于WebP是否真的胜过JPG的文章中对此进行了详细比较。

我应该对眼前的文件做什么？

打开压缩器。对你的文件运行两次。如果是照片，先选择智能模式，然后将滑块推到60，并在完全放大时比较两个输出。如果它包含文本或透明度，请保持PNG并尝试两种PNG模式：无损模式将alpha.png压缩到383.9 KB，而调色板模式将其压缩到98.3 KB。当图像要用于800px列时，首先调整大小，因为调整大小工具无损地写入PNG，默认情况下以质量90重新编码其他所有内容。如果目标是文档，JPG会在PDF页面上再次以质量92重新编码，这需要额外的生成来考虑。