CodeKitHub为什么使用它？
- 后台上传大图时提示超过 500 KB 限制？拖进来，把宽度限制到 1920px，轻松压到限制以内还有余量。
- 往微信朋友圈发一组产品照，担心微信自动压缩把画质压花？先在这里批量压缩到合理体积，一次拖进整个文件夹，比手动一张张调省事得多。
- 手上是还没发布的产品设计图或客户的保密照片？完全不上传任何服务器，压缩全靠浏览器里的 canvas 完成。
- 网站测速工具提示因为一张 4 MB 未压缩的横幅图导致首屏加载慢？在这里重新编码，上传前先看清压缩前后的体积对比。
- 四十张旅行照片想直接发微信又不想被自动压得模糊？批量模式一次处理整个文件夹，每张单独生成下载链接。
- 拿不准某张照片到底 JPG 还是 WebP 更小？两种都压一遍，看真实数字对比，别只信经验之谈。
常见问题
压缩后画质会变差吗？
质量 70–85% 时，照片在屏幕上看基本分辨不出差别；低于 50% 才会出现明显瑕疵。例外是文字截图——JPG 下更容易出现毛边，这类图建议选 WebP 输出或把质量保持在 85% 以上。
有文件大小或数量限制吗？
没有。压缩在你的设备上进行而不是服务器，所以没有任何限制——50 MB 的大图或一次 100 张都可以，只是大图会多花一点时间。
我的图片会被上传吗？
不会。文件完全由浏览器通过 HTML5 canvas 读取和重编码。你可以打开页面后断网，照样继续压缩。
输出选 JPG 还是 WebP？
同等画质下 WebP 通常小 25–35%，现代浏览器都支持——放网站首选。JPG 在任何软件、打印机上都能打开——分享和邮件首选。拿不准就选 JPG。
为什么我的 PNG 压缩后小了那么多？
PNG 是无损格式，存照片非常费空间——同样的照片 PNG 往往比看不出差别的 JPG 大 5–10 倍。把照片类 PNG 转成 JPG/WebP 是收益最大的压缩。PNG 只留给需要透明或锐利边缘的图形。
为什么有时输出反而比原图大？
如果原图已经被深度压缩过，再编码帮不上忙，甚至会增加字节。出现这种情况时工具会提示——保留原图即可。
这是有损压缩还是无损压缩？
本工具输出的 JPG 和 WebP 都是有损压缩——会舍弃部分图像数据来换取更小体积，这也是为什么有质量滑块。不提供无损重压缩（那种方式只靠去掉冗余字节省 10-20%、不改动任何像素）；照片类内容用 75-85% 的有损质量能获得大得多的收益，且肉眼看不出差别。
压缩会不会去掉照片的 EXIF 信息（拍摄参数、GPS位置）？
会——通过 canvas API 重新编码生成的是全新文件，不携带任何 EXIF 元数据，包括 GPS 坐标、机型和拍摄时间。如果你要公开分享私人照片，这其实是隐私上的额外好处；但如果你依赖 EXIF 做归档整理，这就是个副作用需要注意。
能不能把 PNG 转成 JPG 或 WebP 但基本不压缩画质？
可以——把质量滑块调到 95% 以上。格式仍会转换，但除了格式转换本身带来的差异外几乎没有额外损失（PNG 的透明通道会被铺上白色背景压平）。
这个工具支持哪些输入格式？
JPG、PNG、WebP，以及浏览器 <img> 标签能原生解码的大多数格式。iPhone 默认拍照格式 HEIC 和相机 RAW 格式浏览器无法直接解码，需要先用手机或相机自带软件转成 JPG。
工具介绍
图片压缩通过用更高效的（有损）参数重新编码来减小文件体积。手机拍的照片通常 3–8 MB，而放到网页、聊天或邮件里，200–500 KB 在屏幕上看起来毫无差别。更小的图片上传更快、加载更快、更省存储和流量。
本工具用浏览器自带的编码器按你选的质量重新编码，并可把过大的图片缩放到合理的最大宽度——这是影响体积最大的两个手段。压缩率和画质永远是取舍，每张图的压缩前后体积实时显示，方便你找到最佳平衡点。
格式对比：JPG、WebP、PNG 谁更小
同一张照片、同样的观感、三个悬殊的体积：PNG 是重量级（无损——照片类内容常是 JPG 的 5–10 倍），JPG 是通用的中间地带，WebP 通常再比 JPG 小 25–35%。所以照片的压缩优先级是：先摆脱 PNG，然后要兼容选 JPG、要极致体积选 WebP。
图形类内容把这张表反过来：截图、logo、纯色 UI 图里，调色板量化后的 PNG 在体积和锐度上通常都赢过 JPG——JPG 的摄影式压缩会把锐利边缘抹花。那个场景有专门的工具。
| 内容类型 | 最佳格式 | 原因 |
|---|---|---|
| 网页/邮件/聊天用的照片 | WebP（要兼容性就用JPG） | 有损压缩适合照片类细节；同等画质下 WebP 比 JPG 小 25–35%。 |
| 截图、logo、纯色UI图 | PNG | 无损——JPG 的摄影式压缩会让文字和锐利边缘变模糊。 |
| 需要透明背景的图 | PNG 或 WebP | JPG 没有透明通道；PNG 和 WebP 都支持透明背景。 |
| 追求最大兼容性（老软件、打印机） | JPG | 从上世纪90年代起就通用；WebP 支持虽晚但现在浏览器已基本全覆盖。 |
性能说明
- 先缩尺寸再谈压缩：4000px 缩到 1920px 直接去掉约 77% 的像素——任何质量滑块都拼不过这一步。
- 批量处理在你的 CPU 上顺序执行，一百张手机照片在笔记本上大约几分钟。因为不经过服务器排队，通常仍比上传型网站快——而且离线也能用。
- 那个 −% 数字就是你的反馈回路：只有个位数时说明图已被优化过，再降质量会先伤观感后省体积。
- 网页发布的参考预算：内容图 ≤200 KB、全宽大图 ≤500 KB——这个量级在移动网络下能稳住 Core Web Vitals。
隐私与元数据：EXIF 信息去哪了
手机或相机拍出的每张照片都带着 EXIF 元数据：精确的拍摄地点 GPS 坐标、机型、拍摄时间，甚至用过哪个软件修过图。把这样的原图直接发到公开网站，任何人查看文件元数据都可能扒出你的家庭住址。
本工具基于 canvas 重新编码，生成的新图片不携带任何这类元数据——这是压缩流程本身的副作用，不是一个需要单独开关的功能，但对于要公开发布私人照片的场景很有用。如果你确实需要保留 EXIF（比如照片归档或版权信息），压缩一份副本使用，同时保留未处理的原图存档。
我们自己的实测记录
这个工具上线前，我们用程序生成的测试图跑过完整流程，并且是逐像素检查输出，不是肉眼扫一眼。一张 3000×2000 的多色 PNG，在 75% 质量 + 1920px 上限的设置下从 140 KB 压到 94 KB（−33%）；因为测试图是合成的，我们能精确验证像素偏差在 JPG 编码器的预期容差之内。另外专门验证了"已是最优"的提示逻辑：喂给它一张已被深度压缩的 JPG，它会诚实提示你保留原图，而不是假装帮了忙输出一个更大的文件。
使用方法
- 把图片拖到虚线框（或点击选择），支持 JPG、PNG、WebP。
- 设置质量：75% 是均衡值；追求最小体积可降到 60%。
- 选择最大宽度——网页全屏用 1920px 足够。
- 输出格式选 JPG（通用）或 WebP（更小，现代浏览器都支持）。
- 点每条结果旁的"下载"。每个文件都显示压缩后大小和节省百分比。
示例
- 输入
手机照片.jpg — 4.20 MB，4032×3024- 输出
手机照片-compressed.jpg — 0.48 MB（−89%），1920×1440
缩放到 1920px 并按 75% 质量重编码：任何屏幕上看起来一样，体积小 9 倍。