手机拍的照片发不出去，很多时候卡在一个很朴素的原因上：文件太大。主流邮箱和网站后台的上传上限普遍在 20 到 25 MB 之间，而一张 1200 万像素的手机原图在高质量编码下轻易就是 3 到 5 MB，HEIC 拍的可能还更大。常见的解法就是用更低的画质重新编码一遍，本页做的正是这件事，用的还是浏览器自带的图像编码器。关键在于这一步跑在你自己的标签页里：人们拿来压缩的，往往是还没发布的产品截图、身份证件扫描件、孩子的照片，一旦这些图片被传到别人的服务器，一个便利功能就变成了数据安全问题。这里没有任何上传：页面没有上传接口，解码、缩放、重编码都由本机的 canvas 与 Blob API 完成，关闭标签页结果就随之消失。
浏览器重编码到底做了什么
三步，全在本地。第一步把文件解码成位图，图片会被完整展开到内存里——一张 1200 万像素的 JPEG，光像素数据就要占掉约 36 MB。第二步按你指定的尺寸把位图画到 canvas 上。第三步用 toBlob 重新编码成文件，此时画质参数只对有损格式有意义：PNG 是无损格式，浏览器会直接忽略这个参数；JPEG 的默认值大约是 0.92。由此带来两个结论。原文件里的 EXIF 元数据——机型、拍摄时间、GPS 坐标——都保留着，而新编码出来的副本一个都没有，因为 EXIF 存在 JPEG 容器里，不在浏览器交给你的像素数据中，这对隐私是好事，对依赖方向标记的人却是实打实的损失：竖拍的照片如果绘制时没有应用 EXIF orientation 标记，导出来就会是躺倒的。
画质档位怎么选，而不是靠猜
没有普适的最优值，但有站得住脚的默认值。给网站用的照片，多数人会落在 0.7 到 0.8：体积通常能砍掉一半以上，而在正常屏幕尺寸下几乎看不出差别。到 0.9 左右基本属于视觉无损，低于 0.5 编码器就会开始抹平细节纹理——草地、头发、布料——这时候就该停手了。有两类内容表现完全不同：截图和纯色图形应保持 PNG，把无损图转成有损，文字边缘反而会出现原本没有的振铃。而已经压过的 JPEG 是最差的输入：每保存一次就是新一代产物，同一张图连压五次就等于叠了五代的伪影，务必每次都从原图开始。
什么时候缩尺寸比降画质更划算
文件体积主要由像素数量决定，而不是画质。6000×4000 的照片即使压到 0.9 仍有 3 MB，把长宽各减一半就砍掉了四分之三的像素，也大致砍掉四分之三的字节数。所以损失最小的顺序是：先裁掉用不上的部分，再缩到图片实际显示的尺寸——桌面端的首屏横幅很少需要超过 2000 像素宽——最后才动画质。如果某个服务既限文件大小也限像素尺寸，那就只有缩尺寸这一条路能过。本地工具同样做不到把没拍到的细节变出来，把小图强行放大去做印刷品，发虚是必然的。
常见问题
图片会被上传到服务器吗？
不会。本页没有上传接口，解码、重绘、重新编码全部发生在你的浏览器标签页里，关掉标签页结果就没了。需要说明的是，本站靠广告维持，广告服务商会看到页面层面的信息，比如你的 IP 地址和访问了哪些页面，但你的图片文件不在其中。
能压掉多少体积？
完全取决于原图。一张细节丰富的照片用 0.75 重编码后，体积常常能减少 50% 到 70%；而一张本来就存成高效 PNG 的截图反而可能变大，因为把无损图再无损编码一遍纯属浪费。在看到你的文件之前，没有任何诚实的工具能给出固定比例，所以先拿一张样本试试，再批量处理。
压缩 JPEG 会让画质变糊吗？
在大多数人使用的档位下不会，但压缩本质上是一次重新编码，也就意味着真实的一代损失。劣化通常不是变糊，而是天空里先出现块状色块，其次是细节边缘的涂抹。原始文件请留好；如果需要一份几乎一模一样的版本，就保持 0.9 以上，接受更小的体积收益。
断网还能用吗？
页面加载完成之后可以。压缩是本地 JavaScript 执行的，网络中断不会影响它。第一次打开仍然需要联网加载页面，之后可以在同一个标签页里继续操作，或在支持离线的浏览器中打开已保存的页面。