JPEG XL and Google Images: check the fallback before changing website pictures

Watercolour and ink illustration of matching tree photographs in a brass optical cabinet, viewed through two different lenses

If your website team is introducing JPEG XL pictures, ask one extra question before the change goes live: what image will Google be able to read? A photograph looking fine in a browser does not establish that its format is supported in Google Images or as a Discover preview.

Google’s John Mueller clarified on 15 October that JPEG XL is currently unsupported in those places. The discussion continued on 23 October, with a useful warning about judging an image by its filename. For a Bath retailer, wedding venue or local charity refreshing a picture-heavy website, this is a small compatibility check worth including in the handover.

What has Google actually said?

JPEG XL is an image format, often identified by a .jxl filename. It is different from the familiar JPEG format. Mueller’s clarification concerns Google’s image handling; it is not an announcement that websites using JPEG XL receive a ranking penalty.

Google’s current image guidance lists JPEG, PNG, WebP, AVIF, GIF, BMP and SVG as supported formats. JPEG XL is absent. The same guidance explains how a page can offer alternative versions of a picture while retaining a fallback image.

If your website already serves supported formats successfully, this news alone is no reason to replace its pictures or buy a new optimisation service. It matters most when a developer, plugin or image-delivery service is changing what the website sends out.

Keep a supported fallback

A website can offer a newer format to browsers that understand it and keep another version available. Developers commonly arrange this through the HTML picture element, which groups alternative image sources around a regular img element.

Google says it finds images through the src attribute of that img element, including when it sits inside picture. It recommends retaining a fallback URL there because some browsers and crawlers do not understand the alternatives. In the original discussion, Mueller confirmed that the included img element makes this approach workable for search engines.

In plain English, ask your maintainer to keep a supported picture, such as JPEG, WebP or AVIF, in that fallback position. Merely using a picture element does not help if its fallback also points only to JPEG XL. You do not need to edit the code yourself; ask the person responsible for the website to show what the published page supplies.

A filename is only a clue

The later replies raised an apparent contradiction: why could someone find .jxl addresses in Google Images if the format was unsupported? Chrome developer advocate Barry Pollard checked examples and reported that the files he examined were actually supplied in other formats, despite their extensions.

Mueller also noted that image extensions and file types are commonly swapped. These observations do not establish support for JPEG XL. They show why searching for a filename, or looking at the name in a media library, is an unreliable compatibility test.

An image-delivery service can change what it supplies without changing the address. Ask the maintainer to inspect the actual response and decoded format, including any automatic conversion. Renaming a .jxl file to .jpg is not an image conversion and should not be treated as a fix.

Check the preview picture too

The picture visitors see within a page may differ from the image nominated for a search preview. Websites can suggest a preferred image through page information such as an og:image tag or structured data. Ask the maintainer to check those image addresses as well, keeping the nominated picture relevant and in a supported format.

Google’s Discover guidance explains that these choices can influence its thumbnail selection. They cannot guarantee inclusion. Discover is a personalised content feed, and Google warns that its traffic is less predictable than visits from ordinary keyword searches.

Make the handover specific

Choose a small sample of important public pages: perhaps a venue gallery, a product page and an article. Have the maintainer confirm the visible photograph, supported fallback and nominated preview image on each. Include pages generated by different templates, because a working homepage does not prove every gallery behaves the same way.

Keep the original photographs and record what changed. Check the published pages on mobile as well as desktop, including whether important details survive cropping and whether descriptive alternative text remains useful. This sits naturally within routine website and search checks, alongside making pages clear and usable for customers.

The aim is a reliable image delivery change. A supported fallback removes an avoidable compatibility problem; it does not promise indexing, a Discover appearance, higher rankings or more enquiries.

Sources