跳到正文
DevTools / 图片转换与压缩

图片转换与压缩

图片体积通常是页面加载时间中占比最大的单项,而一张照片以质量 90 导出与以质量 75 导出,肉眼往往看不出差别,在网络上却可能相差几百 KB。本转换器用浏览器自带的编解码器批量处理图片,可缩放、旋转,在 JPEG、PNG、WebP、AVIF 之间转换,并逐张给出转换前后的体积,让某个设置的实际效果可被测量而不是靠猜。

完全在浏览器本地运行——不会上传任何内容。

或将文件拖到此处
转换在本地通过 canvas 完成,图片不会离开你的设备。
拖入或选择图片开始,文件不会上传。

工作原理

这些格式各有擅长。JPEG 是为照片设计的有损格式:它丢弃人眼不敏感的高频细节,以牺牲锐利边缘和文字周围的质量换取大幅体积下降。PNG 是无损的并支持透明通道,因此适合截图、图标、示意图以及任何边缘锐利或需要透明的内容,而不适合照片——存照片时它的体积会是 JPEG 的好几倍而没有任何可见收益。逐图选择格式,而不是全局统一,是收益最大的一步。

WebP 与 AVIF 是现代选项,所有当代浏览器都已支持。WebP 在同等视觉质量下通常比 JPEG 小 25% 到 35%,同时支持有损、无损和透明通道,因此可以同时取代两种旧格式。AVIF 压缩得更狠——往往比 WebP 再小 20%——但编码更慢,格式也更新,面向老客户端时仍值得准备回退方案。本工具对两者都做特性检测而非想当然,因为一个在格式不受支持时静默失败的转换器,比一个明确拒绝的更糟。

质量是一个传给编码器的百分比,但它不是线性刻度,可用的区间比数字暗示的更窄。对 JPEG 而言,感知上显著的区间大约是 60 到 85:低于 60 时边缘会出现块状伪影、渐变会出现色带;高于 85 时体积急剧上升,而几乎没有人能看出差别。正确的选择方式是比对输出而不是对数字做推理,这也是本工具展示前后体积并允许你按原尺寸查看结果的原因。

缩放是另一个大杠杆,而且它与质量相互作用。把一张 4000 像素宽的照片塞进 400 像素的位置,大部分字节都被浪费了,因此把最长边限制在显示宽度的大约两倍通常是合适的——用两倍而不是恰好相等,是为了在高密度屏幕上依然锐利。适配模式决定宽高比如何处理:contain 在框内保持比例,cover 保持比例并填满框、裁掉溢出,exact 拉伸,none 保持原尺寸。旋转是不带元数据的真实变换,同时会读取 EXIF 方向,避免竖拍照片被悄悄转成横的。

常见应用场景

  • 把一批 PNG 截图转成 WebP,为文档站点减重。
  • 在上传到有体积限制的站点之前压缩照片。
  • 把图片缩小到页面实际显示的尺寸。
  • 把带透明区域的 JPEG 转成 PNG 或 WebP,以保住透明度。
  • 发布前按 EXIF 方向批量旋转手机拍摄的照片。
  • 在站点全面采用某个质量设置之前,先测量它究竟能省下多少。

最后更新: 2026-10-14

常见问题解答

应该使用哪种格式?

今天网页上的绝大多数场景用 WebP,因为它同时处理照片类和图形类内容且支持透明,所有当代浏览器都支持。需要最大兼容性、或下游系统不接受 WebP 时用 JPEG。必须保持逐比特一致的图片(例如构建步骤会比对校验和)以及小尺寸图标用 PNG,后者用无损压缩确实高效。当最后那百分之二十的体积值得换取更慢的编码时,用 AVIF。

质量应该设成多少?

JPEG 和有损 WebP 从 80 开始试,然后对比。低于约 60 时,文字和锐利边缘周围的伪影会变得可见;高于 85 时体积上升很快而差别通常难以察觉。不同格式的数值不可直接比较——WebP 的 80 与 JPEG 的 80 观感并不相同——所以应当看输出而不是从表格里挑数字。这里展示的体积数据能让你看到每一步的代价。

图片会被上传到服务器吗?

不会。转换通过 canvas API 使用浏览器自身的图片解码与编码能力,文件不会离开你的机器,也不会发起任何网络请求,打开浏览器开发者工具即可确认。这对机密图片很重要,例如内部系统的截图、未发布的设计稿或含个人数据的文档。这也意味着页面加载完成后工具可以离线工作。

为什么转成 PNG 后文件反而变大了?

因为 PNG 是无损的,它精确存储每一个像素而不是近似表达图像。对照片而言,这意味着体积是同等 JPEG 的好几倍,却看不出任何差别,因为照片内容没有可供无损压缩利用的冗余。PNG 适合大面积纯色、锐利边缘或带透明的图片,不适合照片。格式互转也不会提升画质:JPEG 转成 PNG 后依然和原来一样有损,只是更重了。

相关工具