JPEG XL SEO: Safe Google Images & Discover Setup

Q: Does Google Images support JPEG XL?

Not according to Google’s current supported-format list, which lists BMP, GIF, JPEG, PNG, WebP, SVG and AVIF but not JPEG XL.

Q: Can I still use JPEG XL on an SEO-focused website?

Yes. Put JPEG XL in a source element inside picture and keep a Google-supported format in the fallback img src.

Q: Which format should I use for the fallback?

WebP, AVIF, JPEG or PNG are practical supported choices. Test file size and visual quality for each asset.

Q: Will JPEG XL automatically improve rankings?

No. JPEG XL is a performance and image-quality option, not a ranking guarantee.

Quick answer: You can serve JPEG XL to compatible browsers, but do not use a .jxl file as the only image that Google must discover. Google’s current image documentation lists BMP, GIF, JPEG, PNG, WebP, SVG and AVIF—not JPEG XL—as supported formats. Put JPEG XL in a <source> inside <picture>, keep a supported WebP, AVIF, JPEG or PNG in the fallback <img src>, and use that supported fallback for og:image and structured data.^[1]^[2]

Copy-paste JPEG XL markup that is safer for SEO

<picture>
  <source
    type="image/jxl"
    srcset="/images/product-800.jxl 800w,
            /images/product-1600.jxl 1600w">
  <source
    type="image/avif"
    srcset="/images/product-800.avif 800w,
            /images/product-1600.avif 1600w">
  <source
    type="image/webp"
    srcset="/images/product-800.webp 800w,
            /images/product-1600.webp 1600w">
  <img
    src="/images/product-1600.jpg"
    srcset="/images/product-800.jpg 800w,
            /images/product-1600.jpg 1600w"
    sizes="(max-width: 800px) 100vw, 800px"
    width="1600"
    height="900"
    alt="Describe the image accurately and concisely"
    loading="lazy"
    decoding="async">
</picture>

The order matters: a compatible browser checks the <source> options and selects a usable format, while the <img> remains the fallback. MDN documents the same fallback behavior for the <picture> element.^[3]

The implementation checklist

[ ] Keep JPEG XL in a <source type="image/jxl">, not as the only <img src>.
[ ] Make the fallback <img src> a format on Google’s supported list.
[ ] Keep a real src value even when you also use srcset.
[ ] Point og:image to the supported fallback, not the .jxl file.
[ ] Use the supported fallback URL in Article, Product, Recipe or other structured-data image fields.
[ ] Give the fallback image a descriptive filename and useful alt text.
[ ] Set intrinsic width and height to reduce layout movement.
[ ] Check the rendered HTML, not only the page-builder or optimization-plugin settings.
[ ] Test the fallback URL directly and confirm it returns HTTP 200 with the correct image content type.
[ ] Recheck Google’s supported-format list before removing fallbacks in the future.

Why this became an SEO issue

Chrome 155 began shipping JPEG XL decoding support in October 2026. Chrome’s engineering team says the format can provide 30–50% better compression than JPEG and supports lossless compression, HDR and lossless JPEG transcoding. The team recommends testing both AVIF and JPEG XL rather than assuming one format is best for every image.^[4]

Browser display support and search-image support are separate questions. A browser may render a .jxl file successfully while Google Images or a Google Discover preview still relies on a supported fallback. Google’s own image SEO page currently tells site owners to provide a fallback URL in the src attribute and lists seven supported image formats; JPEG XL is not on that list.^[1]

Google Search Advocate John Mueller also said JPEG XL was not currently supported for Google Images and Discover previews, according to Search Engine Journal’s report of his October 15 comments. He said the normal <img> inside a <picture> element provides a workable path for search engines.^[2]

What not to do

1. Do not replace every image URL with .jxl

A blanket replacement can leave Google without a supported image URL in the HTML, social metadata or schema. Use progressive enhancement: offer JPEG XL to clients that can use it while preserving a supported fallback.

2. Do not rely on a CSS background for an important SEO image

Google says it finds images in the src attribute of an <img>, including an <img> inside <picture>, and does not index CSS images. Product photos, article lead images and other search-important visuals should therefore remain in semantic HTML.^[1]

3. Do not set og:image to the JXL-only asset

Keep the social and Discover candidate image in a currently supported format. Use the same approach for structured-data image URLs. This reduces the chance that the page is valid but its preferred preview image cannot be processed.

4. Do not remove originals immediately

Keep the supported source files and stable URLs during the transition. That makes rollback simple and protects existing image-search URLs, shares and cached previews.

WordPress: a practical deployment method

WordPress image optimization varies by host, CDN and plugin, so verify the final HTML instead of trusting a toggle labeled “next-generation images.” A safe rollout looks like this:

Choose a small group of non-critical photographic images.
Generate JPEG XL variants without deleting the existing JPEG, WebP or AVIF files.
Configure the delivery layer to emit a <picture> element with JPEG XL as a <source>.
Keep a supported image in the final <img src>.
Leave the WordPress featured image and the SEO/social image on a supported format unless you have verified that the plugin generates a separate supported fallback URL.
Purge the page and CDN caches.
View page source and search for <picture, image/jxl, <img and og:image.
Open each fallback URL in a private browser window and check its response.
Inspect the page in Google Search Console after recrawl when that data becomes available.

If your optimization plugin rewrites the <img src> itself to .jxl and does not preserve a supported fallback, turn that mode off. Compression savings are not worth creating an image-discovery blind spot.

Metadata example

<meta property="og:image"
      content="https://example.com/images/product-1600.webp">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image"
      content="https://example.com/images/product-1600.webp">

In Article schema, use the same supported URL or a supported high-resolution alternative:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "image": [
    "https://example.com/images/product-1600.webp"
  ]
}

How to audit a site after enabling JPEG XL

Check the rendered source

Confirm that each important <picture> ends with an <img> whose src is JPEG, PNG, WebP, AVIF, GIF, BMP or SVG. Google’s documentation specifically recommends the fallback src because some browsers and crawlers may not understand every responsive-image attribute.^[1]

Check preferred preview URLs

Inspect og:image, Twitter card markup and each schema image property. None should depend exclusively on JPEG XL while Google’s format list excludes it.

Check image accessibility and context

Use descriptive alt text, a short descriptive filename and nearby relevant copy. Google says it uses alt text, page content and computer-vision signals to understand an image; keyword stuffing is not useful.^[1]

Check performance with real measurements

Compare transferred bytes, Largest Contentful Paint and visual quality for JPEG XL, AVIF and WebP variants. Chrome’s announcement recommends trying both AVIF and JPEG XL, and says JPEG XL may be especially useful for high-fidelity or lossless photographic use cases.^[4]

Decision guide

Use JPEG XL now: when high-fidelity photography, HDR, lossless workflows or progressive decoding justify the extra pipeline complexity.
Test before broad rollout: when a CDN or WordPress plugin controls markup and you cannot yet confirm its fallback behavior.
Wait: when the only deployment option replaces supported URLs, metadata and schema with JXL-only files.
Never remove the fallback solely because a browser displays JXL: rendering support does not prove search-preview support.

FAQ

Does Google Images support JPEG XL?

Not according to Google’s current supported-format list. It lists BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. JPEG XL is absent.^[1]

Can I still use JPEG XL on an SEO-focused website?

Yes. Put it in a <source type="image/jxl"> inside <picture> and keep a supported format in the fallback <img src>.^[1]^[3]

Which format should I use for the fallback?

WebP, AVIF, JPEG or PNG are practical choices depending on the image. All four are on Google’s current supported list. Test file size and quality rather than selecting one format for every asset.^[1]

Should my featured image be JPEG XL?

Not as the only version. Keep the featured, social-preview and structured-data image available at a supported URL while using JPEG XL as an optional browser source.

Will JPEG XL automatically improve rankings?

No. A smaller image may improve delivery, but the format itself does not guarantee rankings. Treat JPEG XL as a performance and quality option, then verify crawlability, fallback markup, image relevance and real page performance.