Image format choice is trapped in a false assumption: that PNG is universal and only needs a compression pass. In reality the cost of choosing the wrong format dwarfs the cost of compression tuning. The same image can be three times smaller as WebP than as PNG, and ten times smaller as JPEG. This guide gives rules per scenario; the in-site format converter and compressor perform every conversion described here.
The four formats differ fundamentally in how they compress. Lossless modes (PNG, WebP lossless) restore every pixel exactly, which suits flat artwork. Lossy modes (JPEG, WebP lossy) discard high-frequency detail the eye barely perceives, shrinking photographs to a tenth of their size but losing detail permanently. That is why a PNG photograph resists compression: the lossless algorithm is nearly ineffective against gradients and noise.
Selection depends on a single question: does the image contain large areas of contiguous flat colour? If yes, use PNG — or better, SVG. Screenshots, icons, buttons, text and diagrams compress extremely well as PNG; a 512x512 icon can be 3KB. If no, use JPEG, WebP or AVIF: photographs, gradient backgrounds and noise-heavy illustration often end up larger as PNG than the original, because noise defeats run-length encoding. This test is the underlying logic behind the in-site compressor, which picks PNG lossless or JPEG lossy accordingly.
Transparency has a cost. PNG's 8-bit mode supports only fully transparent or fully opaque; 32-bit RGBA adds partial alpha at double the size. JPEG has no alpha channel at all. So a black background after converting transparent PNG to JPEG is not a bug — JPEG has nowhere to put alpha, and converters either drop it or fill a solid colour. Keep PNG when transparency matters, or use WebP or AVIF, which offer both transparency and high compression.
Animation is where intuition misleads most often: converting an animated GIF to WebP often makes it bigger. GIF uses LZW over a fixed palette with no inter-frame differencing. WebP's inter-frame prediction excels at simple motion — translation, fades — but fails on broadly changing content, storing full frames when prediction misses. Simple looping animations shrink 30–50% as WebP; per-frame animations such as hand-drawn or particle effects should stay GIF or move to video. The in-site GIF compressor lets you compare the real sizes before committing.
Lossy degradation is cumulative, so conversion order matters. Keep a lossless master, convert once to the target format at quality 90, and perform every resize, watermark and crop on the master. The anti-pattern is JPEG → watermark → save JPEG → resize → save JPEG: four lossy steps in sequence, and quality visibly degrades. A related trap is that conversion may drop EXIF orientation; a phone photo rotated 90 degrees via EXIF lies down after conversion. The in-site cropper reads orientation first and then applies the transform, avoiding exactly this.
One rule is often missed but pays off well: resize before compressing. If the display target is 400px wide and the source is 4000px, compressing the 4000px original wastes 90% of the pixels. Resize to the target dimension first, then convert and compress once.
The selection table in the Chinese section condenses this: SVG for icons with PNG fallback; PNG or lossless WebP for interface screenshots; WebP with AVIF as progressive enhancement for content photos; JPEG or lossy WebP for decorative backgrounds; WebP or AVIF when alpha is required; WebP for simple loops; GIF or video for complex animation; ICO for desktop application icons.
A practical checklist: decide PNG versus JPEG-family by looking for flat colour; never convert to JPEG when alpha matters; measure animated formats before choosing since WebP can exceed GIF; keep a lossless master and transcode exactly once; confirm EXIF orientation survives; resize to the display dimension before compressing.