压缩图片到 600KB
精确落在 600KB，而不是「差不多低于它」。文件不上传。
- 不上传
- 精确命中目标体积
- 原生批量
拖入图片，或点击选择
JPG / PNG / WebP / HEIC · 单张最大 25MB · 支持批量
文件不上传服务器，全部在你的浏览器里完成。
总进度
这张图片暂时处理不了
600KB 是硬门槛，不是建议值
写着「最大 600KB」的表单，会拒掉 601KB 的文件。多数压缩工具只承诺「已经压过」，于是用户提交、被拒、把质量滑块拉低、再试一次。这里做的是：在编码后的字节数 ≤ 600KB 的前提下搜索最高质量，然后把实际字节数直接报给你。
为什么偏偏是 600KB
600KB 是很多论坛和社区的默认上限，设这个数是因为它们按图片数算存储费。600KB 下 1500×1000 还能保持质量 85，已经比任何网页排版会显示出来的尺寸都大。
600KB 的限制通常从哪来
- 电商平台与 CMS 上传：单图限制 500KB
- 微信、WhatsApp 传文件：500KB 在手机上依然清楚
- 学校、HR、保险系统：明确写「小于 500KB」
- 冲印店与相册排版：每页接受 1MB
如果表单同时规定了像素（例如 600×600），先定体积再看输出尺寸——两个条件有时会互相冲突。
600KB 能保住多少分辨率
在 JPEG 质量 70–80% 的常态下，体积预算可以直接换算成像素预算。下面这些尺寸都还能保持干净：
| 画幅 | 尺寸 | 典型用途 |
|---|---|---|
| 1:1 | 1340×1340 | 头像、2×2 证件照 |
| 3:2 | 1650×1100 | 相机默认、冲印 |
| 16:9 | 1790×1010 | 屏幕、幻灯片 |
这些数字是算出来的，不是抄来的：字节 ÷ 0.34 ≈ 可用像素。在 600KB 下超过这个尺寸，皮肤和文字就开始出现块状痕迹。
为什么压一次往往打不准
JPEG 的体积和质量不是线性关系：90% 降到 80% 可能直接减半，80% 到 70% 却只省 15%。只猜一次，要么超标，要么白白浪费 40KB 的空间。这里的做法是编码、量体积、收窄区间，直到输出落在限制的 2% 以内；如果最低质量仍然压不到目标，就改为降低像素尺寸，而不是交给你一张废图。
600KB 该导 JPG、WebP 还是 PNG？
同样的 600KB 下，WebP 的画质大约比 JPG 好 8–12%，还能保住透明通道——但少数老旧政务门户仍然拒收 .webp，先确认表单接受哪些类型。JPG 处理照片最稳：所有门户都认，代价是透明区域被铺白（或你选的底色）、细文字边缘发软。PNG 是无损格式，「600KB」根本不可能靠降质量达到——工具会改为降低像素尺寸，这对截图、logo、线稿是正确取舍，对照片通常不是。
隐私：文件从来没有离开这个标签页
整个过程不会发出上传请求。浏览器解码图片、在 worker 线程里重新编码，然后交给你一个下载用的 blob。你可以打开 DevTools → Network，拖进一张图，确认没有任何请求带着它出去。断网也能用。