W październiku 2026 JPEG XL dostał w ciągu jednego tygodnia to, na co czekał od lat: 6 października Chrome 155 włączył go domyślnie, 13 października zrobił to Firefox 158. Dziewięć dni po premierze Chrome John Mueller z Google przypomniał, że Google Grafika i podglądy w Discover tego formatu nie obsługują. Jeśli planujesz podmienić obrazy na .jxl, bo przeglądarki wreszcie je czytają, to właśnie teraz łatwo zrobić sobie krzywdę w SEO. Poniżej zbieram, co dokładnie napisał Mueller, co mówi dokumentacja, jak po październikowych premierach wygląda stan w przeglądarkach i jak sam wdrażałbym ten format.

Co napisał John Mueller

15 października 2026 Mueller napisał na Bluesky, że jeśli komuś zależy na pokazywaniu obrazów w Google Grafika i jako podglądów w Discover, to JPEG XL „nie jest obecnie obsługiwany”, i podlinkował dokumentację. Barry Schwartz opisał sprawę 23 października w Search Engine Roundtable i stamtąd rozeszła się po branży.

Dokumentacja Google Search Central jest tu jednoznaczna. Wyszukiwarka obsługuje obrazy wskazane w atrybucie src elementu img w formatach BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a rozszerzenie pliku powinno zgadzać się z jego typem. JPEG XL na tej liście nie ma i Mueller nie zapowiedział, że się pojawi.

Sam komunikat nie wnosi więc nic nowego, bo lista formatów wygląda tak od dawna. Nowy jest kontekst: format po raz pierwszy działa domyślnie w głównych przeglądarkach, więc za chwilę ktoś zacznie go wdrażać na produkcji i dopiero wtedy zderzy się z tą listą.

Co zmieniło się w przeglądarkach w październiku 2026

Jeszcze wiosną tego roku dekoder JPEG XL w Chrome siedział za flagą, a w Firefoksie był dostępny tylko w kompilacjach Nightly. Wiele poradników w sieci, także tych pisanych w 2026 roku, nadal opisuje ten stan. Październik go zmienił:

PrzeglądarkaStan obsługi JPEG XLOd kiedy
Chrome 155 i przeglądarki na Chromium (np. Brave 1.97)dekodowanie włączone domyślnie, dekoder jxl-rs napisany w Ruście6 października 2026
Firefox 158włączone domyślnie13 października 2026
Safariobsługa od Safari 17; według serwisu Core Web Vitals częściowa, bez animacji i dekodowania progresywnego2023

We wpisie na blogu Chrome for Developers Google podaje, że JPEG XL kompresuje o 30-50% lepiej niż JPEG, obsługuje kompresję bezstratną i HDR oraz pozwala bezstratnie przekodować istniejące pliki JPEG. Druga część tego wpisu jest ciekawsza. Google zaleca testowanie zarówno AVIF, jak i JPEG XL, i spodziewa się, że nowy format najbardziej przyda się przy fotografii, wysokiej wierności i kompresji bezstratnej oraz tam, gdzie liczy się dekodowanie progresywne. Google traktuje więc JPEG XL jako dodatkową opcję do porównania, a nie następcę AVIF. Cały wpis dotyczy wyłącznie dekodowania.

Droga do tego momentu była długa. W 2022 roku Google usunął z Chrome eksperymentalne wsparcie, tłumacząc, że ekosystem nie wykazuje wystarczającego zainteresowania, a format nie daje dość korzyści względem istniejących, żeby włączać go domyślnie. W styczniu 2026 roku, jak relacjonował The Register, do kodu Chromium trafił dekoder jxl-rs, czyli implementacja w Ruście zamiast referencyjnego libjxl w C++. Dla Mozilli to był warunek: już w 2024 roku zespół Firefoksa mówił, że rozważy JPEG XL, gdy powstanie dekoder w Ruście, bo ma obawy o bezpieczeństwo około 100 tysięcy linii wielowątkowego kodu C++ w libjxl. Ten sam dekoder odblokował więc obie przeglądarki.

Przeglądarka a wyszukiwarka to dwie różne sprawy

Najłatwiej pomylić właśnie te dwa poziomy. Przeglądarka decyduje, czy odwiedzający zobaczy obraz na Twojej stronie. Systemy indeksowania Google decydują, czy ten obraz trafi do Google Grafika, miniatur w wynikach i podglądów w Discover. Po październiku pierwszy warunek jest dla JPEG XL spełniony w trzech głównych silnikach, drugi nadal nie.

Dochodzi do tego trzeci poziom, o którym w dyskusji o Google łatwo zapomnieć: serwisy społecznościowe i komunikatory, które pobierają obraz Open Graph. Z mojego doświadczenia wymagają JPEG albo PNG i o JPEG XL nie słyszały. To moja praktyczna ocena, nie komunikat żadnej z tych firm, ale przy wdrożeniu liczy się tak samo jak lista Google.

Jak to wpływa na SEO obrazów

Na audytach widzę, że strony tracą widoczność w grafice głównie przez jakość wdrożenia: brak tekstu alternatywnego, obrazy wstawiane skryptem po załadowaniu strony, miniatury bez podstrony, na której obraz miałby sensowny kontekst. Format rzadko bywa winowajcą, bo prawie wszyscy używają JPEG, PNG albo WebP. Przy JPEG XL stałby się nim od razu.

Co ryzykujesz, podmieniając format

Jeśli obraz główny artykułu albo zdjęcie produktu będzie dostępne wyłącznie jako .jxl, Google nie daje żadnej gwarancji, że je wykorzysta. W praktyce oznacza to brak albo ograniczoną obecność w Google Grafika oraz słabszą kartę w Discover, gdzie duży obraz w dużym stopniu decyduje o klikalności. Do tego dochodzi opisany wyżej problem z Open Graph.

Osobna pułapka czeka na tych, którzy korzystają z CDN z automatyczną negocjacją formatu po nagłówku Accept. Taki serwer sam decyduje, co wysłać danemu klientowi, i nie wiadomo, jak zachowa się wobec robota Google, gdy do listy formatów trafi image/jxl. Zanim włączysz JPEG XL w takiej konfiguracji, sprawdź w logach, co dostaje Googlebot-Image.

Bezpieczny wzorzec: element picture z fallbackiem

Jeśli chcesz testować JPEG XL już teraz, użyj elementu picture. Przeglądarka wybiera pierwszy source, który obsługuje, a img z formatem z listy Google jest zawsze ostatecznym wyjściem:

<picture>
  <source srcset="zdjecie.jxl" type="image/jxl">
  <source srcset="zdjecie.avif" type="image/avif">
  <source srcset="zdjecie.webp" type="image/webp">
  <img src="zdjecie.jpg" alt="Opis obrazu" width="1200" height="800">
</picture>

Atrybut src w img powinien wskazywać format z listy Google. Dokumentacja mówi właśnie o obrazach z src elementu img, więc to tam ma stać plik, który ma trafić do indeksu. Nie traktuję tego jako potwierdzenia, że Google po prostu pominie source z JPEG XL, a sam wpis Google o Chrome 155 nie zawiera żadnych wskazówek o picture ani fallbackach. To jednak najbezpieczniejsze ułożenie, jakie znam.

Co zamiast tego poprawi wyniki

Jeśli celem jest szybsze ładowanie, a nie sam format, masz obsługiwane rozwiązania pod ręką. AVIF i WebP zwykle dają duże oszczędności względem JPEG i oba są na liście Google. Wpływ na LCP i na Core Web Vitals w ogóle zależy bardziej od poprawnych wymiarów, priorytetu ładowania obrazu głównego i braku lazy loadingu na elemencie LCP niż od zmiany formatu. O tym, jak obrazy działają w wyszukiwaniach wizualnych, piszę szerzej w tekście o optymalizacji treści pod kątem wyszukiwań wizualnych.

Czego nie wiadomo

Glenn Gabe zauważył 23 października 2026 roku, że w Google Grafika widać zaindeksowane pliki .jxl, a zapytanie o typ pliku zwraca je razem z innymi formatami. Ciekawa obserwacja, ale słowom Muellera nie przeczy, bo obecność w indeksie nie oznacza oficjalnego wsparcia, stabilnego zachowania ani obecności w Discover. Nie wiadomo też, czy to efekt uboczny, test, czy pojedyncze przypadki.

Nie ma też żadnej informacji, czy i kiedy Google dopisze JPEG XL do dokumentacji. Skoro ta sama firma wydaje dekoder w Chrome i chwali format na własnym blogu, zgaduję, że to kwestia czasu, ale to tylko moje przypuszczenie. Planowanie wdrożenia na jego podstawie byłoby zgadywaniem za cudze pieniądze.

Podsumowanie

JPEG XL po październiku 2026 ma wreszcie przeglądarki po swojej stronie, ale dla widoczności obrazów w Google nadal nie jest bezpieczny. Dokumentacja wymienia BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a Mueller potwierdził, że to aktualny stan. Jeśli eksperymentujesz z .jxl, rób to w elemencie picture, w src elementu img zostaw format z listy Google, a przy CDN z negocjacją formatu sprawdź, co dostaje robot. Po wdrożeniu obserwuj w Search Console raport wydajności z filtrem na typ wyszukiwania „Grafika”, bo tam najszybciej zobaczysz, czy coś się posypało.

Często zadawane pytania

Czy Google Grafika obsługuje JPEG XL?

Nie. Dokumentacja Google wymienia BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a John Mueller potwierdził 15 października 2026, że JPEG XL nie jest obecnie obsługiwany.

Czy obrazy JPEG XL pojawią się w Google Discover?

Mueller zaznaczył, że JPEG XL nie jest obsługiwany także dla podglądów w Discover. Jeśli zależy Ci na Discover, obraz główny trzymaj w JPEG, PNG, WebP albo AVIF.

Które przeglądarki obsługują JPEG XL?

Chrome od wersji 155 (6 października 2026) i Firefox od wersji 158 (13 października 2026) dekodują JPEG XL domyślnie. Safari obsługuje format od wersji 17, według serwisu Core Web Vitals bez animacji i dekodowania progresywnego.

Czy warto przechodzić na JPEG XL dla szybszego ładowania strony?

Na dziś bezpieczniej wybrać AVIF lub WebP, które Google obsługuje w wyszukiwarce. Sam Google radzi porównać AVIF i JPEG XL na własnych obrazach. JPEG XL testuj z fallbackiem w elemencie picture i obrazem w obsługiwanym formacie w img.

Skoro w Google Grafika widać pliki .jxl, to znaczy, że format działa?

Nie. Glenn Gabe zauważył zaindeksowane pliki .jxl, ale oficjalna dokumentacja ich nie wymienia. Obecność w indeksie nie jest gwarancją wsparcia.

Źródła

  1. Search Engine Roundtable: JPEG XL Image Format Not Supported By Google Images & Google Discover https://www.seroundtable.com/google-jpeg-xl-42352.html
  2. Google Search Central: Image SEO Best Practices: Use supported image formats https://developers.google.com/search/docs/appearance/google-images#supported-image-formats
  3. Bluesky: John Mueller o braku wsparcia JPEG-XL (15.10.2026) https://bsky.app/profile/johnmu.com/post/3mxw5yrrd322v
  4. Chrome for Developers: Shipping JPEG XL in Chrome https://developer.chrome.com/blog/jpeg-xl-in-chrome
  5. Firefox: Firefox 158.0 Release Notes https://www.firefox.com/en-US/firefox/158.0/releasenotes/
  6. JPEG XL: Software Support https://jpegxl.info/resources/software-support.html
  7. The Register: Google rekindles relationship with jilted JPEG XL image format https://www.theregister.com/2026/01/14/google_rekindles_relationship_with_jilted/
  8. Core Web Vitals: JPEG XL and Core Web Vitals: what you need to know now that Chrome ships it https://www.corewebvitals.io/pagespeed/jpeg-xl-core-web-vitals-support