JPEG、PNG 和 WebP 压缩不是同一个问题
正确的压缩策略取决于图像格式以及必须保留的属性。JPEG 通常用一部分视觉保真度换取更小文件，PNG 往往可以在不改变像素的情况下无损优化，而 WebP 根据源文件和编码器可以包含有损或无损图像数据。
最近技术复核： 2026-09-19
关键结论
- 更小的图像并不自动等同于原图。
- 像素尺寸、Alpha 透明度、文件格式和元数据是不同属性，需要分别做出明确决定。
- 重新编码即使保留宽度和高度，也经常会去掉原始元数据。
- 经过验证的压缩器应在提供输出前解码或检查自己生成的文件。
JPEG：受控的有损重压缩
JPEG 面向照片类图像，通常采用有损压缩。使用较低质量重新编码可以在保持像素尺寸的同时节省字节，但会丢弃一部分图像信息。
反复 JPEG 重压缩会累积伪影，因此压缩器应使用有边界的质量策略，而不是无限降低质量。
PNG：无损像素与结构选择
PNG 支持无损图像数据和 Alpha 透明度。无损优化器可以重新组织扫描行或选择更高效的过滤方式，而不改变解码后的像素值。
不同 PNG 变体的处理复杂度不同。调色板、隔行扫描、高位深以及不常见的 chunk 都可能需要单独支持。
WebP：格式支持与编码器行为都很重要
WebP 支持多种编码模式，包括透明度。浏览器原生编码的元数据行为可能与源文件不同，也不意味着所有 WebP 功能都会被保留。
专用压缩器应定义受支持的输入变体，保留要求的尺寸和 Alpha 行为，并确认输出确实是 WebP。
为什么 ZAMAZY 把工具分开
ZAMAZY 为 JPEG、PNG 和 WebP 分别提供压缩工具，而不是使用一个通用按钮。每个工具都有自己的支持规则和验证检查。
JPEG 工具明确接受有损重压缩，PNG 路径专注无损像素保留，而 WebP 输出会在受支持范围内验证格式、尺寸和透明度。
示例与决策参考
照片、带小号文字的截图以及透明 Logo 的优先级并不相同。可以接受一定损失时，JPEG 适合照片；当解码像素和 Alpha 必须精确保留时，无损 PNG 更合适。WebP 支持多种模式，但 ZAMAZY WebP 压缩器使用受限的有损重编码流程，而不是格式允许的全部模式。
根据现有文件格式选择对应压缩器。这些专用工具不是格式转换器，也不是尺寸调整工具。检查输出中的文字边缘、渐变、颜色和透明边界。宽高不变并不能证明 RGB 像素完全不变。质量值是编码器设置，不是通用视觉评分，也不是可以在不同浏览器间直接比较的百分比。
哪些情况下不适合这种方法
保留 Alpha 并不能证明色彩配置、动画或所有元数据字段都被保留。已经高度压缩的输入可能无法得到更小且可接受的结果。如果要求像素完全一致、动画、印刷色彩流程或指定的新格式，不应仅因扩展名受支持就用有损压缩代替这些要求。
编辑性示例，不是 benchmark。补充内容复核日期：
来源与证据边界
这些来源用于解释格式和方法，并不认证 ZAMAZY。ZAMAZY 实际支持的事实与限制以对应工具页面为准。
- MDN: Image file type and format guide — 不同图像格式的取舍；格式本身的能力不代表工具一定支持。
- W3C: PNG Specification, Third Edition — PNG 像素、Alpha 与 chunk；不表示所有 PNG 变体都受支持。
- Google: WebP Container Specification — WebP 模式、Alpha、动画和元数据容器。
- MDN: HTMLCanvasElement.toBlob() — 编码格式和质量参数；不代表经过认证的元数据删除能力。
第一方厂商研究：PNG 无损保留
状态：已验证。 ZAMAZY 使用未修改的 PNG 引擎处理三个固定、完全合成的 PNG 文件，然后再次解码每个结果并进行结构比较。
这是第一方厂商研究，不是独立认证。测试输入为了易于压缩而有意使用 zlib 压缩级别 0，因此不能代表典型压缩 benchmark。
| Fixture | 尺寸 | 输入 | 输出 | 已验证的保留项 |
|---|---|---|---|---|
rgb-flat-v1 | 256 × 64 | 49,284 B | 252 B | Scanline 相同; 非 IDAT chunk 相同; 未产生更小输出时拒绝第二次处理 |
rgba-pattern-v1 | 64 × 32 | 8,292 B | 4,700 B | Scanline 相同; 非 IDAT chunk 相同; Alpha 相同; 未产生更小输出时拒绝第二次处理 |
gray-metadata-v1 | 64 × 32 | 2,199 B | 158 B | Scanline 相同; 非 IDAT chunk 相同; 未产生更小输出时拒绝第二次处理 |
负面用例
在已验证环境中，截断的 zlib 数据、无效 Adler-32 校验和以及 zlib 数据流后的额外数据都会被拒绝。
truncated-zlib: 已拒绝invalid-adler32: 已拒绝trailing-zlib-data: 已拒绝
方法与适用边界
研究比较了优化前后的解码 scanline、页面几何和所有非 IDAT chunk；RGBA 用例还明确比较了 Alpha。独立的控制解压使用 Node zlib，但它不是外部独立验证机构。
这些证据只适用于已记录的 fixture 和指定引擎版本。它不能证明所有 PNG 变体、浏览器网络行为、设备支持、典型压缩率，也不能证明任意用户文件都安全。
研究 png-preservation-v1 · 复核日期 · Node 22.22.3 / zlib 1.3.1-e00f703 / linux x64 ·引擎 commit a12415a3a19f
常见问题
PNG 一定比 JPEG 大吗？
不一定，取决于图像。照片通常更适合 JPEG，而平面图形、文字型图像和透明内容可能更适合 PNG。
尺寸不变是否意味着图像无损？
不是。宽度和高度可以完全相同，但 JPEG 或有损 WebP 在编码时仍会丢弃视觉信息。
为什么压缩后元数据会消失？
浏览器重编码通常会创建新的图像数据流，而不是复制原始容器元数据。EXIF、GPS 等信息如果必须保留，需要明确的支持。