Compress to target size
Enter a target size (e.g. 100KB); the tool binary-searches quality and, if needed, resolution to get the image under it.
把图片拖到这里，或点击选择
支持 JPG / PNG / WebP / GIF / BMP，可多选；原始文件只被读取，导出的是新文件，原图不会被修改
目标体积与压缩设置
提示：JPG / WebP 都是有损格式，同一张图反复压缩会累积损失（每次都会重新编码）。想尽量保画质，就少压几轮、或先用Image crop把多余部分裁掉再压。
怎么把图片压到「刚好不超过 100KB」？
为什么很多平台要限制图片体积：报名系统、考试网报、政务与银行 App、部分招聘平台都会写明"照片不超过 100KB""附件单个不超过 1MB"。这类限制来自两头的成本——服务器要长期存储海量上传件，带宽要按流量计费，页面加载速度也直接受图片体积影响。限制本身不会因为你的图片"内容更重要"而放宽，所以正确做法不是反复试，而是把图片一次压到限制以内。常见门槛从 20KB（部分证件照）到 500KB、1MB（简历附件）不等，本工具就是为这些硬指标准备的。
为什么按「目标体积」压，而不是拖质量滑块：质量滑块（如 80%、60%）给的是"压缩力度"，你无法预知压完是 60KB 还是 300KB——同一张图在不同质量下的体积差异可能有好几倍，还跟画面复杂度强相关。结果是只能"压一次 → 看体积 → 不够再压一次"，每压一次就多损失一次画质，而且第二轮是在已经损失过的图上再损失。把目标设成 100KB，让程序去反推需要的画质，一次到位，画质损失最小。
二分搜索是怎么找到那个画质的：JPEG / WebP 的体积随质量参数单调上升，质量越高体积越大。所以程序先在质量区间 0.05~0.95 上取中点试压，如果结果 ≤ 目标就说明"还能更好"，往上半区间继续找；如果超标就往下半区间找。固定 8 步后区间就被切到原来的 1/256，得到的就是"满足 ≤ 目标 的最高质量"。这比从 95% 一路往下试快得多，也更接近"刚好达标"的最优解。
什么时候必须牺牲尺寸（分辨率）：如果质量已经降到 5% 仍然超标，说明瓶颈不在压缩率而在像素太多——一张 4000×3000 的照片，再低的画质编码后也压不到 20KB。这时唯一的办法是缩小分辨率：真实场景里 100KB 以内的照片，边长通常只有 600~1000 像素。开启「允许缩小分辨率」后，程序会按 85% 逐轮缩短最长边（最多 6 轮），每轮重新二分搜索质量，并在结果里如实标注最终尺寸与画质。如果你的平台要求"尺寸不变"，就关掉这个开关——但那样可能无法达标，页面会告诉你最小只能到多少。
关于隐私：整个压缩过程都在你的浏览器里完成，图片不会被上传到任何服务器——可以打开浏览器开发者工具的 Network 面板自行确认，整页不会出现任何文件上传请求。身份证、证件照、工资条、合同这类敏感图片因此也可以放心处理。同样因为不上传，导出速度只取决于你的电脑，不消耗流量也不排队。
FAQ
It already hit the limit within 'allow downscaling'. Try in order: (1) make sure 'allow downscaling' is on (off, only quality drops remain, which often can't get there); (2) switch output to WebP - typically 25%-35% smaller at the same quality; (3) crop away excess whitespace first with our image crop tool - halving the area roughly halves the size; (4) if the image is already a heavily re-encoded high-quality JPEG, re-encoding gains very little - go back to the original photo and compress that instead.
Because the input is already smaller than your target: 'compressing' would only degrade quality without reliably shrinking size (re-encoding can even grow it). The tool says 'already under target, no compression needed' and offers to export the original verbatim - not a single byte changed.
No. The browser can only read the file you picked; it exports a new file (name suffixed with something like -100KB) into your Downloads folder. Your original is never modified or deleted under any circumstance.
JPG itself has no transparency channel. With 'fill PNG transparency with white' checked, a white base is laid down before encoding - the usual white-background ID effect; unchecked, the browser decides, which may be black or messy color patches. To keep transparency, choose WebP output.
JPEG / WebP are lossy: every save re-encodes, and blocking artifacts and banding accumulate - so always start from the original instead of compressing an already-compressed file. Also, browsers cannot decode HEIC (iPhone's default photo format): convert it first with our 'HEIC to JPG' tool on this site (photos are processed locally, not uploaded), then come back here.