Format arguments usually start from the codec and work outwards. That is backwards. The right format is decided by what is in the picture, and only then by what the receiving system accepts.
Photographs: JPEG or WebP
Continuous-tone images — faces, landscapes, anything with gradients and noise — compress well with lossy codecs, because the eye tolerates small errors in busy areas. JPEG is the safe default because everything accepts it. Lossy WebP reaches the same perceived quality in noticeably fewer bytes, so it wins whenever the destination allows it.
One caveat if you are using ToolZool for this: our compressor writes WebP only in its lossless mode, which on a photograph produces a file several times larger than the JPEG would be. For a photograph with a size limit, pick JPEG here. The reason for that gap is on the compressor’s own page — there is no lossy WebP encoder we can ship without either an incompatible licence or a C toolchain.
Flat graphics and text: PNG
Logos, icons, diagrams and screenshots of user interfaces are made of hard edges and large areas of identical colour. Lossy codecs handle hard edges badly: you get visible ringing around text, and because the noise they introduce is itself expensive to encode, the file often ends up larger than a lossless PNG of the same image.
Transparency forces the choice
JPEG has no alpha channel. Convert a transparent PNG to JPEG and the transparent areas become solid — usually black, sometimes white, rarely what you wanted. PNG and WebP both support alpha, so if the image has transparency the shortlist is those two.
Where AVIF fits
AVIF beats WebP on file size at matched quality, particularly at low bitrates, and every current browser can display it. Encoding is the problem: it is dramatically slower and far heavier to run than JPEG or WebP, which matters when the encoding happens on a phone rather than a build server.
ToolZool neither reads nor writes AVIF today. Both directions need an AV1 codec, and every maintained one is a C library that does not build for WebAssembly — so an AVIF file has to be converted in something else first. The same is true of HEIC, which most iPhones produce by default.
The question that overrides all of this
What does the form accept? A better format that gets rejected is not better. Read the accepted list first, then optimise inside it — and if a file that looks like it should qualify is still refused, why an upload form rejects your file works through the four checks a form actually runs. If you need to move between formats, the image compressor reads JPG, PNG and WebP and writes JPEG, PNG or lossless WebP, so it doubles as a converter within that set.
