Format choice comes down to one question more than any other: does this
image have smooth continuous tone, like a photograph, or flat regions
and sharp edges, like a screenshot or a logo? Lossy formats (JPG,
WebP, AVIF) win decisively on the first. Lossless formats (PNG, GIF)
win decisively on the second. Nearly every bad format decision comes
from getting that one call backwards.
The table below is the overview; the entries beneath it go into what
each format costs you in practice.
| Format | Compression | Transparency | Animation | Best at |
| JPG | Lossy (DCT) | None | No | Photographs, anything that must open everywhere, print submissions |
| PNG | Lossless (DEFLATE) | Full 8-bit alpha channel | APNG variant only; poorly supported | Screenshots, logos, diagrams, line art, transparency, working masters |
| WebP | Both lossy and lossless | Full 8-bit alpha, in both modes | Yes | Essentially everything published on the web |
| AVIF | Both lossy and lossless | Full 8-bit alpha | Yes | Maximum compression where you control delivery |
| GIF | Lossless (LZW), within a 256-colour palette | 1-bit only: fully on or fully off | Yes, and the reason it survived | Legacy systems that demand it, pixel art, flat-colour graphics |
| SVG | Vector: XML markup instead of pixels | Inherent: the canvas is empty by default | Yes, via CSS or SMIL | Logos, icons, diagrams, anything that must be sharp at any size |
| BMP | None, in practice | A variant exists; support is unreliable | No | Nothing, as a delivery format |
- Compression
- Lossy (DCT)
- Transparency
- None
- Colour
- 24-bit (16.7M colours)
- Animation
- No
- Support
- Universal: every browser, device and application
The safest possible choice for a photograph and the wrong choice for almost anything else. Degrades a little every time it is re-saved, so treat a JPG as a delivery format rather than a working one.
Reach for it when
Photographs, anything that must open everywhere, print submissions.
Avoid it for
Text, screenshots, sharp edges, transparency, repeated re-saving.
Routes: PNG → JPG · WebP → JPG · GIF → JPG · BMP → JPG · SVG → JPG · AVIF → JPG
- Compression
- Lossless (DEFLATE)
- Transparency
- Full 8-bit alpha channel
- Colour
- 24-bit, plus 8-bit alpha
- Animation
- APNG variant only; poorly supported
- Support
- Universal
The default for anything that is not a photograph. Its lossless guarantee makes it the right container while you are still editing, and its alpha channel is the most reliably supported transparency anywhere.
Reach for it when
Screenshots, logos, diagrams, line art, transparency, working masters.
Avoid it for
Photographs, routinely 3-5× the size of an equivalent JPG.
Routes: JPG → PNG · WebP → PNG · GIF → PNG · BMP → PNG · SVG → PNG · AVIF → PNG
- Compression
- Both lossy and lossless
- Transparency
- Full 8-bit alpha, in both modes
- Colour
- 24-bit, plus 8-bit alpha
- Animation
- Yes
- Support
- All current browsers since 2020; patchy in older desktop software
The sensible modern default. Roughly 25-35% smaller than JPG on photographs at matched quality, roughly 20-26% smaller than PNG on graphics, with transparency in both modes. If you are publishing to a browser, this is usually the answer.
Reach for it when
Essentially everything published on the web.
Avoid it for
Handing files to old desktop viewers, some print workflows.
Routes: JPG → WebP · PNG → WebP · GIF → WebP · BMP → WebP
- Compression
- Both lossy and lossless
- Transparency
- Full 8-bit alpha
- Colour
- Up to 12-bit; HDR and wide gamut
- Animation
- Yes
- Support
- Chrome, Firefox, Opera, recent Safari; limited outside browsers
The efficiency champion, often half the size of a comparable JPG. The costs are slow encoding and patchy support outside browsers, which is why "my computer will not open this file" is now a common complaint about AVIF specifically.
Reach for it when
Maximum compression where you control delivery.
Avoid it for
Anything handed to software you do not control; fast encoding.
Routes: AVIF → JPG · AVIF → PNG
- Compression
- Lossless (LZW), within a 256-colour palette
- Transparency
- 1-bit only: fully on or fully off
- Colour
- 256 colours per frame
- Animation
- Yes, and the reason it survived
- Support
- Universal
A compatibility format rather than a quality one. Photographs band visibly and usually get larger, not smaller. Flat graphics with under 256 colours convert perfectly. For animation, a video file is commonly 95% smaller.
Reach for it when
Legacy systems that demand it, pixel art, flat-colour graphics.
Avoid it for
Photographs, gradients, soft edges, animation (video is far better).
Routes: JPG → GIF · PNG → GIF · WebP → GIF
- Compression
- Vector: XML markup instead of pixels
- Transparency
- Inherent: the canvas is empty by default
- Colour
- Unlimited
- Animation
- Yes, via CSS or SMIL
- Support
- All browsers; rejected by many upload forms and app stores
Not really competing with the others: it stores instructions rather than pixels, so it scales infinitely and a complex logo can be two kilobytes. Keep artwork as SVG wherever possible; rasterise only when something refuses to accept it.
Reach for it when
Logos, icons, diagrams, anything that must be sharp at any size.
Avoid it for
Photographs, which it cannot meaningfully represent.
Routes: SVG → PNG · SVG → JPG
- Compression
- None, in practice
- Transparency
- A variant exists; support is unreliable
- Colour
- 24-bit
- Animation
- No
- Support
- Universal to read; almost nothing produces it deliberately
A source format, never a destination. It turns up as output from scanners, screen-capture utilities and older industrial software. Converting a BMP to WebP routinely lands around 1% of the original size with no visible change.
Reach for it when
Nothing, as a delivery format.
Avoid it for
Everything: a 12-megapixel image is around 36 MB.
Routes: BMP → PNG · BMP → JPG · BMP → WebP