Fixing Images Served in the Wrong Format

The four kinds of wrong format

The Image Optimisation audit reports a format problem when the format in use is heavier than it needs to be for that kind of image. In practice almost every case falls into one of four groups, and each has a different fix.

1. A photograph in a lossless format. PNG keeps every pixel exactly, which is ideal for a screenshot and wasteful for a photo of a sofa, where the camera noise alone makes the file huge. This often happens when a designer exports everything from the same tool with the same setting, or a PNG is needed for transparency on one image and becomes the habit for all of them.
2. An animation in GIF. GIF is limited to 256 colours per frame and compresses poorly, so even a few seconds of animation can weigh several megabytes. A short muted video is usually a small fraction of that size.
3. A drawing saved as pixels. Logos, icons and simple diagrams are made of shapes. Saved as JPEG they get blurry edges and coloured fringes; saved as PNG they are sharp but need a separate file for each size. SVG describes the shapes themselves, stays sharp at any size, and is often tiny.
4. No modern alternative. The image is a sensible JPEG or PNG, but browsers that support AVIF or WebP are not offered them, so they download a larger file than necessary.

The first three are about choosing the right format for the content. The fourth is about delivery: keeping a widely readable fallback while giving capable browsers something smaller.

Choosing a format for each kind of image

Decide by what the image contains, not by habit. These questions settle most cases:

• Is it drawn from shapes and flat colour, such as a logo, icon or line diagram? Use SVG, cleaned up with a tool such as SVGO, which removes editor metadata and hidden layers.
• Is it a photograph or anything with gradients and texture? Use AVIF or WebP for browsers that accept them, with JPEG as the fallback.
• Does it need transparency, such as a product cut out on a clear background? WebP and AVIF both support transparency, so a large transparent PNG photo can usually become a much smaller WebP or AVIF with a PNG fallback.
• Is it a screenshot with small text or a chart with thin lines? Lossless WebP or a well-optimised PNG keeps text crisp. Lossy compression tends to smear small type.
• Does it move? Use MP4 or WebM video in a <video> element, or an animated WebP or AVIF if it must be an image.

AVIF, WebP or both

AVIF often gives smaller files than WebP for photos at similar visual quality, but it is slower to encode and not every tool or platform produces it. WebP is quicker to encode and very widely supported by software. Offering both, AVIF first, is the most thorough approach; WebP alone is still a clear step up from JPEG and PNG, and a reasonable place to stop if your pipeline cannot produce AVIF.

Converting images properly

Always convert from the best source you have: the camera original, the design export or a high-quality master. Converting an already heavily compressed JPEG to WebP or AVIF bakes its blocky artefacts into the new file, and each lossy step adds more.

One-off images

Squoosh, a free browser-based tool, lets you compare the original and the converted image side by side with a quality slider, which is the best way to learn what setting each kind of image tolerates.

Batches from the command line

# WebP, lossy, for photographs
cwebp -q 80 sofa.jpg -o sofa.webp

# WebP, lossless, for a screenshot with text
cwebp -lossless dashboard.png -o dashboard.webp

# AVIF with libavif; quality flag names vary between versions,
# so check avifenc --help for yours
avifenc -q 60 sofa.jpg sofa.avif

# ImageMagick 7 can do either
magick sofa.jpg -quality 80 sofa.webp

# Clean up an SVG logo exported from a design tool
npx svgo logo.svg -o logo.min.svg

In a Node.js build or upload handler

import sharp from 'sharp';

const src = sharp('masters/sofa.jpg');
await src.clone().avif({ quality: 50 }).toFile('public/img/sofa.avif');
await src.clone().webp({ quality: 78 }).toFile('public/img/sofa.webp');
await src.clone().jpeg({ quality: 80, mozjpeg: true }).toFile('public/img/sofa.jpg');

Quality numbers are not comparable between formats or encoders. A quality of 50 in one AVIF encoder is not the same as 50 in WebP or JPEG. Pick settings by comparing images by eye on a few typical photos, then apply them to the rest. Compression settings in more depth are covered in the guide to oversized image files.

Two ways to serve modern formats

1. The picture element

The page lists each format and the browser takes the first one it supports. It works on any host, needs no server changes and is easy to inspect. The cost is longer markup and three files per image.

<picture>
  <source type="image/avif" srcset="/img/sofa.avif">
  <source type="image/webp" srcset="/img/sofa.webp">
  <img src="/img/sofa.jpg" width="1600" height="1067"
       alt="Green velvet two-seater sofa with walnut legs">
</picture>

The alt, width, height and loading attributes all go on the <img>, which is the element the browser actually displays whichever source it picks.

2. Content negotiation on the server or CDN

Browsers send an Accept header listing the image types they can decode. The server can read it and send AVIF or WebP from the same URL, keeping the markup as a plain <img>. Many image CDNs and platforms do this automatically. On your own Nginx server, with converted files stored beside the originals, it looks like this:

map $http_accept $img_suffix {
    default        "";
    "~image/avif"  ".avif";
    "~image/webp"  ".webp";
}

server {
    location ~* ^(/img/.+)\.(jpe?g|png)$ {
        add_header Vary Accept;
        try_files $1$img_suffix $uri =404;
    }
}

With this in place, a request for /img/sofa.jpg from a browser that accepts AVIF receives /img/sofa.avif, and other browsers get the JPEG. The Vary: Accept header tells caches that the response depends on that header.

Finding out what format is really delivered

File extensions are not reliable. A URL ending in .jpg may deliver WebP from a negotiating CDN, and a .webp file may have been renamed from a PNG without conversion. Check what arrives:

1. Open developer tools, go to the Network panel, reload and filter by images. The Type column shows the format the browser received. Sort by size to see the heaviest first.
2. Click a large image and check the Content-Type response header. It should say image/avif, image/webp, image/jpeg, image/png, image/svg+xml or image/gif.
3. Test negotiation from the command line by sending different Accept headers:

# What a modern browser receives
curl -sI -H "Accept: image/avif,image/webp,*/*" https://www.example.co.uk/img/sofa.jpg | grep -iE "^content-type|^vary"

# What an older client receives
curl -sI -H "Accept: */*" https://www.example.co.uk/img/sofa.jpg | grep -iE "^content-type|^vary"

If both requests return image/jpeg, nothing is negotiating. If the first returns AVIF or WebP but there is no Vary header, caching may go wrong. Record the results for your heaviest images before you change anything, so you can measure the saving afterwards.

The fix, step by step

Places where modern formats cause trouble

• Social share images. The image in og:image is fetched by each platform's own crawler, not by a browser, and support for newer formats varies. Keep share images as JPEG or PNG. The Open Graph image size guide covers the rest of their requirements.
• Email. Many email clients do not display WebP or AVIF. Images in newsletters and transactional emails should stay JPEG, PNG or GIF.
• Feeds and marketplaces. Shopping feeds, marketplaces and print services each publish their own accepted formats. Check before pointing them at converted files, or keep a JPEG version at a stable address for them.
• Images people download. Visitors who save an image may not be able to open WebP or AVIF in older desktop software. For downloadable assets such as press kits, offer JPEG or PNG links.
• SVG from untrusted sources. SVG files can contain scripts. Only use SVG you created or have checked, and do not let users upload SVG that is served from your main domain without sanitising it.
• Colour. Convert images to the sRGB colour space during export. Wide-gamut or unusual colour profiles can look different between browsers after conversion.

Stopping old formats creeping back

• Convert at upload or build, not by hand, so every new image gets modern versions without anyone remembering.
• Keep masters, so a better encoder later means re-running a script rather than re-shooting photos.
• Give designers export presets: SVG for logos and icons, high-quality JPEG masters for photos, and no PNG photographs.
• Block large GIF uploads in the CMS, or convert them to video automatically.
• Re-run the audit after theme and plugin changes, which sometimes replace picture elements with plain image tags.

For choosing and configuring a CDN that converts formats for you, see fixing image CDN delivery.