Google Images and Google Discover do not support the JPEG XL image format yet. Google’s John Mueller confirmed this on Bluesky on October 15, 2026, shortly after Chrome and Firefox both added support for the format. A CDN or image plugin that quietly switches to it can pull photos out of Image Pack results and Discover feeds. Search Console won’t flag the cause, so this JPEG XL Google Images support gap is easy to miss.
This piece is a short audit you can run today: what Google confirmed, which formats it actually indexes, and seven checks to make sure none of your images are serving in a format Google can’t read yet.
What Google Confirmed About JPEG XL Google Images Support
The exchange started on Bluesky. Chrome developer advocate Barry Pollard asked whether Google Search could fall back gracefully if a site served JPEG XL inside a <picture> element. John Mueller replied with a direct line: “JPEG-XL is currently not supported.”
Mueller pointed to Google’s own list of supported image formats rather than giving a workaround. Pollard followed up by asking specifically about fallback handling inside a picture element, since JPEG XL is brand new to two major browsers. Mueller confirmed that a proper fallback “would work for any search engine,” a point aimed at Bing and other engines as much as Google.
That is the whole announcement. There was no blog post, no Search Central update, and no date given for when support might arrive. The only record is the Bluesky thread itself, which is why I’m treating this as a confirmed fact from Google, not a rumor.
Why JPEG XL Is Suddenly Showing Up On Sites
JPEG XL has existed for years, but it only recently became a practical default. According to reporting from Search Engine Journal, Chrome began testing the format with a small slice of users on September 23. The wider rollout followed in Chrome 155 on October 6, 2026. Firefox followed with version 158 on October 13. Safari has supported the format since version 17, back in 2023.
Chrome’s own engineering team has described JPEG XL as offering 30 to 50 percent better compression than standard JPEG, along with lossless encoding and HDR support. Those are real performance gains for page speed. The problem is that Core Web Vitals improvements mean nothing for image SEO if Google can’t crawl the result.
Once two of the three major browsers can render JPEG XL, some CDNs and image optimization tools will start serving it automatically to any visitor whose browser reports support. That is normal, sensible behavior for human visitors. It becomes a problem the moment Googlebot’s crawler, which does not behave like a regular browser, hits the same file with no fallback in place.
How JPEG XL Compares to WebP and AVIF
Site owners keep adding newer image formats for a reason: each one trades extra encoding complexity for a smaller file. WebP arrived first and is now supported everywhere, including Google Images. AVIF came next, with better compression than WebP in most real-world tests, and Google added it to the supported list in 2024.
JPEG XL is the newest entrant, and on paper it beats both. It supports lossless transcoding straight from existing JPEG files, so a site can re-encode a huge photo library without any quality loss. That one feature is why some CDNs are eager to default to it. None of that matters for search visibility yet, though, because indexing support hasn’t caught up with browser support.
My practical advice: keep AVIF as your default “next-gen” format for anything you want Google Images or Discover to pick up. Let JPEG XL run only as a bonus format inside a proper picture element, with AVIF or WebP as the fallback, until Google’s documentation changes.
Which Image Formats Google Actually Indexes
Google’s documentation on indexable file types and its image SEO guidance both list the same seven formats for anything referenced in an img tag’s src attribute:
- BMP
- GIF
- JPEG
- PNG
- WebP
- SVG
- AVIF
JPEG XL is not on that list, and neither Mueller’s post nor the documentation gives a timeline for adding it. AVIF is the newest format Google added, confirmed back in 2024, so there is precedent for Google eventually catching up. There just isn’t a date yet.
Google’s guidance also repeats something easy to forget. “Google doesn’t index CSS images,” so any image loaded only through a CSS background-image property was already invisible to Google Images. That rule hasn’t changed, but it’s worth checking while you’re already auditing image markup.
JPEG XL Google Images Support: The 7-Point SEO Checklist
Here’s the audit I’d run on any site right now, in the order I’d actually do it.
1. Check what format your CDN or image plugin serves by default. Open DevTools on a product or blog post page, look at the Network tab, and check the content type of your main images. Many image CDNs auto-select a format based on the visiting browser’s Accept header, which means the format Googlebot receives can differ from what you see in your own browser.
2. Audit every <picture> element for a safe fallback. If you use picture and source tags to serve newer formats, confirm the nested img element’s src attribute points to JPEG, PNG, WebP, or AVIF. Never leave the newest format as the only option. Google’s own documentation recommends always specifying that fallback URL, since some crawlers can’t read picture or srcset at all.
3. Check your og:image and schema.org image URLs separately. These control Discover thumbnails and rich result previews, and they are often set in a theme or plugin setting completely separate from your main content images. A fast way to check: pull the raw HTML of a few key pages and search for every og:image and image schema property.
4. Test real URLs with Search Console’s URL Inspection tool. Run a handful of image-heavy pages through URL Inspection and check the rendered screenshot. If an image is missing or broken in that render, Googlebot likely couldn’t decode the file format being served.
5. Review your image optimization plugin’s settings. On WordPress specifically, several popular image optimization plugins have added or are testing JPEG XL output as browser support grows. Open your plugin’s format settings and confirm JPEG XL isn’t selected as a primary or “next-gen” format until Google catches up.
6. Check your image sitemap entries match the actual served format. If you maintain a separate image sitemap, make sure the URLs it lists resolve to a supported format and not a JPEG XL variant your server might be redirecting to based on browser detection.
7. Set a reminder to recheck Google’s documentation monthly. Google added AVIF to its supported list with no major announcement beyond a single blog post. Support for this format could arrive the same quiet way, so watching the indexable file types page is more reliable than waiting for news coverage.
If you want a code-level check rather than a visual one, a safe fallback pattern looks like this:
<picture>
<source srcset="photo.jxl" type="image/jxl">
<source srcset="photo.avif" type="image/avif">
<img src="photo.jpg" alt="Descriptive alt text here" width="1200" height="800">
</picture>The browser picks the first format it understands, in order, and anything that can’t read picture at all, including some crawlers, falls back to the plain img src. That fallback file is the one Google actually sees, so it has to be a supported format, not a placeholder.
Reading Server Logs for Googlebot Image Requests
DevTools shows you what your own browser receives. Server logs show you what Googlebot actually requested and what your server sent back, which is the more reliable check if you manage your own hosting or CDN.
Filter your access logs for the Googlebot-Image user agent and look at the response content type for a sample of image requests. If you see image/jxl going out to Googlebot’s image crawler on pages that matter for search traffic, that confirms the fallback logic isn’t working and Googlebot is getting a file it can’t decode.
This step takes longer than a DevTools check, so I’d only run it if the quicker checks above turn up something suspicious, like a sudden drop in Image Pack impressions in Search Console’s Performance report.
Does Google Discover Support JPEG XL Previews?
Discover previews work differently from Image Pack results. Google generates the Discover thumbnail from whatever image you set through og:image or schema.org markup, and Google’s own guidance recommends a larger image specifically for this purpose. Neither Mueller’s statement nor Google’s Discover documentation names JPEG XL as a supported source for that preview image, so I’d treat it as unsupported until Google says otherwise.
The safest move is the same one that protects Image Pack visibility. Keep your designated preview image in JPEG, PNG, WebP, or AVIF. Let the newer format stay a bonus option for browsers that already support it, served only through a proper picture fallback.
What This Means If You Run WordPress
My take: this is a low-drama fix if you catch it now, and a confusing traffic drop if you don’t. Most WordPress sites don’t hand-code picture elements. The format choice usually comes from whatever image optimization or CDN plugin is active, and plugin defaults change with updates more often than site owners realize.
I’d start by checking your plugin’s changelog for any mention of JPEG XL, next-gen formats, or automatic format negotiation added in the past month. If you updated an image plugin recently and you’re also seeing an unexplained dip in Google Images referral traffic, this is worth ruling out before you look anywhere else.
This also isn’t a reason to panic about your broader technical SEO setup. It’s a narrow, specific gap tied to one image format and two browser releases from this month. Treat it like any other crawlability check, not a sign that something bigger changed in how Google handles your site.
One more thing worth checking: Jetpack, ShortPixel, Imagify, and most CDN-level image services expose their format rules somewhere in settings, usually under a label like “next-gen formats” or “automatic format delivery.” None of them need to be disabled entirely. You just need the JPEG XL toggle, if one exists, to stay off until Google’s own documentation adds the format to its supported list.
Frequently Asked Questions
Does Google support JPEG XL for Google Images?
Not yet, as of October 2026. John Mueller confirmed on Bluesky on October 15 that JPEG XL isn’t supported, and Google’s indexable file types documentation still lists BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF only.
Will serving JPEG XL hurt my existing rankings?
Text content rankings shouldn’t be affected directly. The risk is narrower: specific images in that format may not get crawled, indexed, or shown in Image Pack results or Discover previews, which can quietly reduce image-driven traffic.
Is AVIF a safe alternative to JPEG XL right now?
Yes. AVIF is on Google’s supported list and has been since 2024, and it offers strong compression with broad browser support, including Chrome, Firefox, and Safari.
How do I know if my site is already serving JPEG XL?
Open any image-heavy page in Chrome DevTools, check the Network tab, and look at the content type returned for your main images. Some CDNs and plugins switch formats automatically based on what the requesting browser reports it can handle.
Has Google said when JPEG XL support might arrive?
No. Neither Mueller’s post nor Google’s documentation gives a timeline. The most reliable signal will be a quiet update to the indexable file types page, similar to how AVIF support was added.
Why This Matters
Browser support for a new image format usually gets treated as a performance story, not an SEO one. This case shows why that split is risky: a format can be “ready” for visitors and still be invisible to Google’s crawlers. The fix here takes minutes, not a rebuild, so there’s no reason to let it slide once you know to check.
- Open DevTools on your top image-driven pages today and confirm the format being served.
- Check your image plugin’s settings for any JPEG XL or “next-gen format” toggle.
- Bookmark Google’s indexable file types page and recheck it monthly until this changes.
Leave a response