Squoosh 上手：浏览器内压缩图片，六种编码器怎么选

Squoosh 是 Google Chrome Labs 维护的在线图片压缩工具。打开 squoosh.app，把图片拖进浏览器窗口，挑一种编码器，调好质量，就能拿到体积明显更小的成品。它针对的是不想装软件、又不放心把原图传给第三方服务器的场景，编码工作全在浏览器内完成。

Squoosh 是什么，图片到底去了哪里

项目 2018 年 3 月建仓，采用 Apache-2.0 许可，在 GitHub 仓库上有约 2.6 万 star。代码分两块：一套网页应用，一组被编译成 WebAssembly 的编解码器。浏览器负责界面，重活交给 Web Worker，编码时页面不会卡住。

隐私是它常被推荐的理由。仓库 README 原文写得很直白：Squoosh 不把图片发给服务器，所有压缩都在本地完成。这一点和把图传到云端再下载的在线服务不同，处理客户截图、身份证照片这类敏感素材时差别很大。

但“不上传图片”不等于“零网络请求”。README 同时说明，站点会通过 Google Analytics 收集基础访客数据、压缩前后的图片体积数值，以及 PWA 安装的类型与时间。文件内容不出本机，使用行为仍会被统计。介意的话，可以在浏览器里装拦截插件，或者干脆自建一份。

六种编码器怎么选

右侧面板决定输出格式。每个编码器的参数和默认值都不一样，默认值本身就能说明它的定位。完整清单可以在 codecs 目录里逐个翻。

AVIF 的默认质量只给到 50，不是它压得狠，而是这个编码器在低质量档的画质损失比 JPEG 小。JPEG XL 在官方面板上标注了 beta，说明还不是稳定通道。

菜单里另有浏览器自带的 JPEG、PNG、GIF 编码通道。想确认某张图到底值不值得换格式，可以先用系统编码跑一遍做对照。

质量、尺寸与色板：三个真正影响体积的旋钮

质量滑杆是显性旋钮，范围 0 到 100，MozJPEG 与 WebP 默认 75。往下拖到 60 附近，多数照片的肉眼差异仍然有限；再往下压，平滑渐变区域会先出现色带。

尺寸往往比质量更划算。一张四千像素宽的图塞进八百像素宽的版位，先把宽高改小，编码压力立刻下降。面板提供 Stretch 与 Contain 两种方式：前者直接拉伸到指定宽高，比例不对就会变形；后者等比缩放，空出的部分补边。

缩放算法有浏览器原生的 pixelated、low、medium、high，也有跑在 Worker 里的 triangle、catrom、mitchell、lanczos3 与 hqx。hqx 适合像素画放大，lanczos3 适合常规照片缩小。需要提醒的是，Squoosh 没有自由裁剪框，想做构图裁剪得先去别的工具处理。

第三个旋钮是减色。面板里的 Reduce palette 会对图片做色彩量化，图标、插画、纯色块多的截图用它能再掉一截体积；照片用了容易出现明显断层，不建议开。

AVIF 面板还多一个 speed 参数，默认 6。数值调小换来更小的文件和更长的等待，调到 0 附近时，一张大图在笔记本上可能要等上十几秒。

一次完整的压缩流程

整个流程没有注册、没有登录，也不需要排队。下面以压缩一张网页首图为例。

1. 打开 squoosh.app，把图片拖进窗口，或直接 Ctrl+V 粘贴剪贴板里的图。
2. 在右侧编码器下拉里选目标格式，先试 WebP 或 AVIF。
3. 拖动质量滑杆，观察右上角的体积读数变化。
4. 拖中间的分割线做左右对比，或切到差异视图看画质损失集中在哪。
5. 需要改尺寸就展开 Resize，填宽高并选好算法。
6. 满意后点下载，文件名会带上编码器与质量参数，方便回溯。

对比视图不只是并排看。切到差异模式后，页面会用 Butteraugli 算一张感知差异热力图，偏亮的区域就是人眼容易察觉损失的地方。调参时盯着热力图，比盯着体积数字更容易判断该不该继续压。

体积读数在拖动滑杆时会实时更新，不必等到下载才知道结果。这对需要卡在某个体积上限的场景很实用，比如邮件附件或图床限制。

离线可用与自建部署

Squoosh 本身是个 PWA。站点提供 manifest.json，display 设为 standalone，用 Chromium 系浏览器打开后，地址栏右侧会出现安装入口。首次加载会把资源缓存下来，之后断网也能继续压图，这对经常出差、网络不稳的人挺实在。

自建也不复杂。仓库 README 给的路径是克隆代码后执行 npm install，再 npm run build 产出静态文件，npm run dev 起本地开发服务。产物是纯静态的，扔到 Nginx 或任意静态托管上即可，不需要数据库和后端进程。

需要说清一点：官方仓库里没有 Dockerfile，也没有 compose 文件。网上流传的 Docker 镜像基本是第三方打包，镜像里的代码版本和构建参数得自己核验。如果单位内网要做离线压图，直接照 README 走 npm 构建这条路更稳妥。

边界与维护状态：什么时候不该用它

边界之一是批量。网页版一次只处理一张图，没有队列、没有文件夹导入。要压几十张素材，得反复拖拽，效率很低。安卓端想做本地批量转换，可以看Image Toolbox 那类工具；桌面端则更适合交给命令行批处理。

边界之二是内存。编码器跑在 WebAssembly 里，几十兆的原图叠加 AVIF 编码，会吃掉一个 CPU 核并占用大量内存。浏览器标签有卡死或被系统回收的风险，处理超大图时，先缩尺寸再压，比直接硬压靠谱。

边界之三是定位。它是压缩与格式转换工具，不是图片编辑器。要在浏览器里改图层、抠图、调色，应该去Photopea；要在浏览器里处理数据而非图片，思路可以参考CyberChef。三者都在本地跑，分工不一样。

维护状态值得如实说。仓库 dev 分支上最后一次功能性提交是 2024 年 8 月 19 日的 Replace deprecated terser plugin，此后没有新功能进入主分支。2023 年 1 月，维护者已经明确停止维护 CLI 与 libsquoosh 两部分，理由是团队人员流失，网页应用继续保留。

仓库没有归档，到 2026 年仍有依赖升级的自动提交推上来，squoosh.app 也照常可以访问。但 issue 列表里挂着 260 多个未关闭的条目，多数没人处理。也有第三方评述把它的状态写成“停在 2024 年 8 月”，结论与仓库提交记录一致，可以互相印证。

放到使用建议上：偶尔压几张图，或要在本地处理敏感素材，Squoosh 依然顺手。想横向比较几种格式的体积差异，它也够用，而且不用装软件。要批量、要接进构建流水线、要长期依赖某个编码器的新特性，就别把它当基础设施，换个有维护的工具更稳。

相关地址

以下为文中项目的官方入口与提到的站内文章，编码器清单、构建方式与隐私说明以这些页面为准。

• Squoosh（在线使用）：https://squoosh.app/
• Squoosh（GitHub 仓库）：https://github.com/GoogleChromeLabs/squoosh
• Squoosh（README 与隐私说明）：https://github.com/GoogleChromeLabs/squoosh/blob/dev/README.md
• Squoosh（编解码器目录）：https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs
• Squoosh（PWA 清单）：https://squoosh.app/manifest.json
• Photopea（站内文章）：https://www.1fdh.com/4688.html
• CyberChef（站内文章）：https://www.1fdh.com/4835.html
• Image Toolbox（站内文章）：https://www.1fdh.com/4682.html