The short answer
For most use cases: JPEG at 75–85% quality, WebP for photos, PNG when transparency is needed — that reliably halves the size while looking identical. If you need to cut 70% or more, quality alone will not do it: reducing the resolution to what is actually displayed often saves more than half on its own, with even less visible loss. The order is always: decide where the image is used → pick dimensions → then quality and format.
Blurring is usually not compression’s fault
Three common illusions. First, compressing a 4000×3000 phone photo and judging it in a small thumbnail: the softness comes from scaling, not quality. Second, the image has already been compressed by a chat app or social platform, so compressing again compounds the loss and amplifies noise. Third, converting a PNG with transparency into JPEG, which turns transparent areas white or ragged — it looks blurred but the format is the problem. Identify which case you are in before tuning anything.
What the quality slider actually changes
For JPEG, the quality value controls how coarse the quantisation table is — in plain terms, how much detail is treated as disposable noise. Going from 100% to 85% discards detail the eye cannot resolve while cutting size by 30–40%; below 60% you start seeing blocking and jagged edges. WebP is typically another 25–35% smaller at the same quality, at the cost of very old software being unable to open it. Screenshots deserve care: text edges are extremely sensitive, and below 70% quality you get visible colour fringing.
Choosing a format
Photos and camera images: WebP first, JPEG when compatibility matters most. UI screenshots and charts: WebP or PNG, never JPEG. Transparency or repeated editing: PNG (lossless, but large). Icons and illustrations: SVG, since bitmaps blur when scaled. Chasing the smallest possible file: try AVIF, but ship a WebP fallback so old devices never see a blank box. The test is simple: does it need transparency? Will anyone zoom in? Does text sharpness matter? Answer those three and the format is decided.
Resolution is the biggest lever
Shrinking a 4000×3000 photo to 1600×1200 leaves 16% of the pixels; combined with 80% quality the file is often a tenth of the original with no visible difference on screen. So before uploading, ask: how wide is it displayed on the page, and on a phone? Preparing twice the display width (for high-density screens) is enough — extra pixels only cost bandwidth. For batches, resize everything to a common long edge first, then compress; two clear steps beat one confusing parameter.
A three-step routine
Step one, keep a backup: lossy compression is irreversible, so set the original aside. Step two, set the target: if a platform caps files at 2 MB, use "compress to target size" in KB; otherwise start from 1600 px on the long edge at 80% quality. Step three, compare: view before and after side by side, focusing on text edges, dark gradients and facial detail, then batch the rest. For documents and ID photos, mask sensitive areas before compressing, and prefer a tool that strips EXIF so your shooting location does not travel with the file.
想马上动手:用 图片压缩 按目标体积压一张试试,或者先看 图片处理专题 里的 28 个工具清单。Try it now: hit a target size with the image compressor, or browse all 28 tools in the image collection.
FAQ
Can I recover the original after compressing?
No. Detail removed by lossy compression cannot be restored, so always keep the original. Material you will edit again (recrop, add text) should be kept in a lossless format.
Which format for screenshots?
WebP first for UI, code and charts, PNG second, and avoid JPEG when text sharpness matters. WebP is usually over 60% smaller than PNG with cleaner text edges.
Will batch compression produce inconsistent results?
The compression strength is consistent within a batch, but final sizes vary with content: detailed or noisy photos end up larger. If you need a uniform size, target a file size instead of fixing quality.