Most format advice is a list of specifications. When you are staring at a file and a form field, you need a decision, so here it is first, with the reasoning afterwards.
The short version: photographs going on the web should be WebP, or JPG if you need maximum compatibility. Anything with sharp edges, flat colour or transparency (logos, screenshots, diagrams, UI exports) should be PNG, or WebP if file size matters more than universal support. Anything that needs to scale to any size should be SVG, kept as SVG. For animation, use a video file, unless a form demands GIF, in which case use GIF. BMP is a source to convert out of and never a delivery format.
That covers perhaps 90% of real decisions. The rest of this guide is the 10%.
The one distinction that matters most
Before comparing formats, separate them into two families, because almost every bad format decision comes from confusing the two.
Lossy formats (JPG, WebP in its lossy mode, AVIF) throw information away to get small. They exploit the fact that human vision is far more sensitive to brightness than to colour, and far more sensitive to large shapes than to fine noise. A lossy encoder discards the parts you were least likely to notice. The result is dramatically smaller and slightly different from the original, and the difference is permanent.
Lossless formats (PNG, GIF, BMP, WebP in its lossless mode) store enough to reconstruct the original pixel for pixel. They compress by finding patterns and repetition and leave the detail alone. Nothing is lost, and files are correspondingly larger for photographic content.
The rule that follows is lossy for photographs and lossless for graphics. A photograph is millions of subtly different colours with no exact repetition, which is the case lossless compression handles worst and lossy compression handles best. A screenshot is large flat regions of identical pixels, which lossless compression eats for breakfast and lossy compression mangles into smeared halos around text.
Get that one call right and you will rarely be badly wrong.
The formats, one at a time
JPG: the universal photograph
JPEG has been the default photographic format since 1992 and is the only format on this list that literally everything can open: every browser, every phone, every print kiosk, every ancient enterprise upload form.
It is lossy, it has no transparency, and it is noticeably less efficient than formats designed thirty years later. It also degrades every time you re-save it, because each save runs a fresh round of lossy compression over already-damaged data. Editing a JPG five times leaves visible artefacts that were not in the original.
Use it when compatibility is the requirement, or when something downstream insists: a submission form, a printer, a client’s ancient software.
PNG: lossless, sharp, transparent
PNG is the workhorse for anything that is not a photograph. It stores every pixel exactly, supports a full 8-bit alpha channel for real soft-edged transparency, and compresses flat colour extremely well. A screenshot of a text editor might be a tenth the size as PNG that it would be as BMP, with zero loss.
Its weakness is photographs, where it is routinely three to five times the size of an equivalent JPG. That surprises people often enough that it has a guide of its own.
Use it for logos, icons, screenshots, diagrams, line art, anything with transparency, and as a working master while you are still editing.
WebP: the sensible modern default
WebP does both jobs. In lossy mode it typically produces files 25-35% smaller than JPG at matched visual quality, and in lossless mode it beats PNG by roughly 20-26% on the same image. It supports transparency in both modes, which JPG cannot do at all, and animation, which PNG effectively cannot.
Browser support has not been a real concern since 2020, since Chrome, Firefox, Edge and Safari all handle it. The remaining friction is outside the browser: some desktop image viewers, older office software and print workflows still refuse it.
Use it for essentially everything you publish on the web. Keep a JPG or PNG fallback only if you know your audience includes people opening files in old desktop software.
AVIF: the efficiency champion, with caveats
AVIF is built on the AV1 video codec and compresses better than anything else here, often producing files half the size of a comparable JPG. It handles transparency, high dynamic range and wide colour gamuts properly.
The costs are real, though. Encoding is slow and computationally expensive. Support outside browsers is still patchy: plenty of desktop software, phone galleries and upload forms simply cannot open an AVIF, which is why “my computer won’t open this file” is now a common complaint. And at very low quality settings AVIF’s failure mode is a soft, smeared, slightly plastic look instead of JPG’s familiar blocking, which some people find more objectionable.
Use it when you control delivery and bandwidth genuinely matters. Convert out of it when you need to hand the file to software that does not speak it.
GIF: compatibility, not quality
GIF is limited to 256 colours per frame. That was a reasonable constraint in 1987 and is a severe one now. Photographs converted to GIF show visible banding in gradients, with skies the classic casualty, and usually end up larger than the JPG they came from, because a palette-based lossless format is a worse fit for photographic data than JPEG compression.
Its animation support is what kept it alive, and even there a modern video file is smaller and better-looking by a wide margin.
Use it when something specifically requires a GIF and nothing else will do. There is more detail on when that is still true.
SVG: outside this competition
SVG is a vector format. It stores shapes, paths and text as instructions and leaves out the grid of pixels. It scales to any size with no quality loss at all, and a complex logo can be a couple of kilobytes.
It only works for artwork that was drawn as vectors. You cannot meaningfully convert a photograph to SVG. Tools that claim to do so trace approximate shapes and produce something enormous that looks like a bad screenprint.
Keep SVG as SVG wherever possible. Convert it to PNG only when something refuses to accept SVG, which app stores, some CMSes and many upload forms still do.
BMP: a source, never a destination
BMP stores pixels essentially uncompressed. A 12-megapixel image is around 36 megabytes. It exists because early Windows needed something trivial to read and write, and it survives mostly as output from scanners, screen-capture utilities and older industrial software.
You should never deliberately produce a BMP for delivery. If you have one, convert it. The size reductions are dramatic, often to around 1% of the original with no visible change.
Side by side
| Format | Compression | Transparency | Best at | Weak at |
|---|---|---|---|---|
| JPG | Lossy | No | Photos, universal support | Text, edges, repeated saves |
| PNG | Lossless | Yes, full alpha | Graphics, screenshots, logos | Photo file size |
| WebP | Both | Yes, both modes | Almost everything on the web | Old desktop software |
| AVIF | Both | Yes | Smallest files | Slow encode, patchy app support |
| GIF | Lossless, 256 colours | 1-bit only | Legacy compatibility | Photos, file size, colour |
| SVG | Vector | Yes | Logos, icons, any size | Photographic content |
| BMP | None | No | Nothing, in practice | Everything |
Three mistakes worth avoiding
Converting JPG to PNG to “improve quality” cannot work. The detail JPEG discarded is gone before the conversion starts, and PNG preserves the damaged version faithfully in a bigger file. What the conversion does buy you is a guarantee of no further loss, which is useful if you are about to edit.
Chaining lossy conversions compounds the damage. Every lossy-to-lossy hop, such as JPG to WebP to AVIF back to JPG, starts from an already-degraded input, so each encoder discards detail based on damaged data. Always convert from the best original you have, not from the last conversion.
Choosing a format for the file you have, instead of the job it is doing, is the third. The question is “what does this specific image need to do”, never “what is the best format”. A logo that must sit on a coloured background needs transparency, which removes JPG from consideration regardless of anything else. A photo destined for a print shop needs universal compatibility, which usually means JPG regardless of how well AVIF compresses.
Deciding in ten seconds
- Does it need to scale to arbitrary sizes and was it drawn as vectors? SVG.
- Does it need transparency? PNG, or WebP if size matters.
- Is it a photograph? WebP, or JPG for maximum compatibility.
- Is it a screenshot, diagram, logo or flat graphic? PNG, or WebP.
- Did something specifically demand a format? Give it that format.
Every one of those conversions runs on this site, in your own browser, without your file being uploaded anywhere. Pick the route off the board and the page for it will tell you what that particular conversion does to transparency, size and metadata.