What this is about
Images are usually the heaviest thing on a web page. On most sites they account for around 60% of the bytes a visitor downloads. Pick the right format and your pages get faster, your hosting bill gets smaller, and your LCP (Largest Contentful Paint) goes down. Pick the wrong one and the opposite happens.
This is a short guide to picking between JPG, PNG, WebP, and AVIF. No drama. Just what each one is for, what they weigh, and how to serve them.
Format choice at a glance
| Format | Lossy | Transparency | Best for | Browser support |
|---|---|---|---|---|
| JPG | Yes | No | Photographs | Universal |
| PNG | No | Yes | Logos, screenshots | Universal |
| WebP | Both | Yes | General replacement | All modern browsers |
| AVIF | Both | Yes | Smallest file size | All modern browsers (2026) |
| SVG | No (vector) | Yes | Icons, diagrams | Universal |
The four formats in plain words
JPG (or JPEG) has been around since 1992. It is lossy, which means it throws away data you probably will not notice in exchange for smaller files. It does not support transparency. It is great for photographs and bad for logos, screenshots, and anything with sharp edges or text.
PNG is lossless. Every pixel is preserved exactly. It supports transparency. The downside is file size: a PNG of a photograph can be five or ten times larger than the same image as JPG. Use it for logos, icons, screenshots, diagrams, and anything where compression artifacts would be visible.
WebP came from Google around 2010 and is now supported by every browser people actually use. It can be lossy (smaller than JPG at the same quality) or lossless (smaller than PNG). It supports transparency in both modes. Think of it as a more efficient replacement for both JPG and PNG.
AVIF is newer. It is based on the AV1 video codec and produces the smallest files of the four. It supports transparency, animation, and HDR. It takes longer to encode on the server, and decoding in the browser is slightly slower than WebP, but in 2026 browser support is solid (Chrome, Edge, Firefox, Safari, Opera all handle it).
Real file sizes
Numbers help. Here is roughly what a 1920x1080 hero photograph weighs in each format at sensible quality settings:
- JPG, quality 80: around 250 KB
- WebP, quality 80: around 150 KB
- AVIF, quality 60: around 100 KB
For a logo or screenshot with a transparent background:
- PNG: around 80 KB
- WebP lossless: around 55 KB
- AVIF lossless: around 45 KB
The exact numbers depend on the image. A photo of a clear blue sky compresses much better than a photo of a forest. But the ranking is consistent: AVIF is smallest, then WebP, then JPG or PNG.
The simple rule for choosing
You do not need a flowchart. The rule is:
- Photos and complex artwork: JPG or WebP-lossy or AVIF. If you can serve modern formats, do.
- Logos, icons, screenshots, diagrams: PNG or WebP-lossless or AVIF-lossless.
- Vector art (logos, icons, illustrations): SVG. It scales to any size and is usually the smallest of all.
- Animation: WebP or AVIF instead of GIF. GIF is huge and limited to 256 colors.
JPG is not dead. It still works everywhere and is fine for compatibility. But if you can serve AVIF or WebP with a JPG fallback, you will save 30 to 50% of bandwidth on image-heavy pages. That adds up.
Serving multiple formats with picture
The picture element lets the browser pick the best format it supports. You list candidates from best to worst and end with a plain img as the universal fallback:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg"
alt="Description of the image"
width="1920"
height="1080"
fetchpriority="high"
decoding="async">
</picture>
A few things going on here:
- The browser walks the source list top to bottom and uses the first format it understands.
- The img inside picture is the final fallback. Its src is what loads if no source matches.
- The width and height attributes prevent layout shift (CLS) while the image is loading. Set them to the intrinsic dimensions of the image.
- decoding=“async” lets the browser decode the image off the main thread.
- fetchpriority=“high” is the next bit.
fetchpriority and your hero image
By default, browsers download images with a lower priority than scripts and stylesheets. They also wait until layout is mostly figured out before they decide which images matter. That is fine for images below the fold, but it slows down your hero image, which is usually your LCP element.
The fetchpriority=“high” hint tells the browser: this one is important, start downloading it now. Use it on:
- The hero image at the top of the page.
- Any image you know is the LCP element.
Do not use it on every image. If everything is high priority, nothing is.
<img src="hero.jpg"
alt="..."
width="1920"
height="1080"
fetchpriority="high">
In our testing this typically shaves 200 to 600 ms off LCP on a slow connection. Not free performance, but close.
Responsive images with srcset
If your layout shows the hero at 1920 px on desktop and 720 px on mobile, do not send the 1920 px file to the phone. Use srcset and sizes:
<picture>
<source
type="image/avif"
srcset="hero-720.avif 720w, hero-1280.avif 1280w, hero-1920.avif 1920w"
sizes="(max-width: 768px) 100vw, 80vw">
<source
type="image/webp"
srcset="hero-720.webp 720w, hero-1280.webp 1280w, hero-1920.webp 1920w"
sizes="(max-width: 768px) 100vw, 80vw">
<img src="hero-1280.jpg"
alt="..."
width="1920"
height="1080"
fetchpriority="high">
</picture>
The browser picks a candidate based on the viewport and the device pixel ratio. A phone gets the 720 file. A retina laptop gets the 1920. Nobody downloads more than they need.
Practical advice that adds up
- Always set width and height on every img tag. This reserves space and stops the page from jumping around as images load. Your CLS score will thank you.
- Lazy load images below the fold with loading=“lazy”. Do not lazy load your hero image, that delays it.
- Generate AVIF and WebP at build time, not on the fly. Tools like sharp (Node), Squoosh (browser), or your image CDN handle this. Most static site generators have a plugin. For one-off batches, the image resizer handles a single file in the browser.
- Strip metadata from photos before publishing. EXIF data can be hundreds of KB and is rarely useful to readers.
- Write real alt text on every image. The image SEO and accessibility guide covers what to write and what to skip.
- Use SVG for icons and logos when you can. It is text, it scales, and it is often under 1 KB.
When WebP is awkward
WebP is great on the web and clumsy off it. Drag a WebP file into older versions of Photoshop and it complains. Send one over WhatsApp Desktop and it sometimes refuses. If you grab images from the web for a slide deck or a document, you will hit this.
We built Save Image As Type for that. It is a small browser extension that lets you save any image as JPG, PNG, or WebP, regardless of what the server sent. Useful when you need a format your other tools can read.
The short version
- For photos, serve AVIF with a WebP fallback and a JPG fallback. Picture element handles the picking.
- For logos and screenshots, use SVG when possible, otherwise PNG or WebP-lossless.
- Set width and height on every image. Use fetchpriority=“high” on your hero. Use srcset for responsive sizes.
- JPG is fine for compatibility. AVIF and WebP just save you bandwidth.
That is most of what you need to know. The rest is tooling.