Kiedy WebP uporządkował web obrazów, a AVIF pokazał, że ten porządek można jeszcze docisnąć, wydawało się, że kierunek jest jasny: coraz mniejsze pliki, coraz lepsza jakość, po kolei. Ale jest jeszcze jeden format, który na papierze poszedł najdalej z całej tej trójki — i który zamiast płynnie wejść do przeglądarek, przeszedł przez trzy lata wygnania. To JPEG XL, w skrócie JXL: standard ISO/IEC 18181, rozwijany przez komitet JPEG, zaprojektowany nie jako kolejny eksperyment, ale jako długoterminowy następca samego JPEG-a.
Na papierze JPEG XL jest dziś technicznie najmocniejszym uniwersalnym formatem obrazu: zwykle lepsza kompresja niż WebP i JPEG, konkurencyjna z AVIF, do tego bezstratna i stratna w jednym, prawdziwe dekodowanie progresywne, którego nie oferuje żaden rywal, oraz jego znak firmowy — bezstratna transkompresja istniejących JPEG-ów, która zmniejsza je o mniej więcej 20% bez utraty jednego piksela i z możliwością odtworzenia oryginału. Problem w tym, że — podobnie jak przy AVIF, tylko mocniej — to, że format jest genialny na papierze, to jedno, a to, czy da się go dziś wygodnie wdrożyć, to zupełnie druga rozmowa. I właśnie tu, jeszcze bardziej niż przy AVIF, warto wrócić do pytania o narzędzia i pipeline, bo z JPEG XL sama specyfikacja mówi najmniej z całej historii. To był zresztą jeden z powodów, dla których powstał ImgOpti v2 — jako odpowiedź na to, że nowoczesne formaty istnieją szybciej, niż nadążają za nimi narzędzia, których używamy na co dzień.
Skąd wziął się JPEG XL
JPEG XL wyrósł ze złączenia dwóch projektów: google’owego PIK i formatu FUIF od Cloudinary. Komitet JPEG połączył je w jeden standard z ambicją większą niż „mniejsze pliki”. Celem było zbudowanie formatu, który zastąpi JPEG na dekady: z najlepszą w klasie relacją wagi do jakości, ale też z funkcjami, których stary JPEG nigdy nie miał — przezroczystością, wysoką głębią koloru, HDR, szeroką paletą barw, animacją i tym progresywnym dekodowaniem, dzięki któremu obraz ostrzeje stopniowo, zamiast doładowywać się od góry.
Najciekawsza jest jednak ta jedna funkcja, która nie ma odpowiednika u konkurencji: JPEG XL potrafi wziąć istniejący plik JPEG i przepakować go bezstratnie, odzyskując około 20% wagi, a potem w razie potrzeby odtworzyć oryginał co do bitu. Dla kogoś, kto ma archiwum kilkudziesięciu tysięcy zdjęć, to nie ciekawostka, tylko konkretna oszczędność miejsca bez żadnego kompromisu jakości.
JPEG XL kontra AVIF i WebP
Najprościej: WebP był rozsądnym kompromisem, AVIF docisnął kompresję, a JPEG XL na papierze bije oba — przy porównywalnej jakości daje zwykle mniejsze pliki, oferuje progresywne dekodowanie, którego nie ma ani WebP, ani AVIF, i jako jedyny umie bezstratnie przepakować stare JPEG-i.
Ale jest jedna rzecz, w której AVIF wygrywa bezdyskusyjnie, i akurat to jest rzecz, która decyduje o wdrożeniu: AVIF naprawdę działa dziś w Chrome, domyślnie, u zwykłego użytkownika. JPEG XL — jeszcze nie. Cała techniczna przewaga JXL rozbija się o to jedno. Do tego, choć JPEG XL obsługuje animację, jego implementacje wciąż nie dorównują tu WebP i AVIF, więc do animowanych obrazów lepiej zostać przy tamtych dwóch.
Dlaczego JPEG XL zniknął — i dlaczego wraca
Tu historia JPEG XL rozchodzi się z historią każdego innego formatu, bo to jedyny z nich, który przeszedł przez otwarty konflikt.
Chrome dodał obsługę JPEG XL za flagą, a potem, pod koniec 2022 roku, w wersji Chrome 110 z lutego 2023 — usunął ją całkowicie, tłumacząc to „niewystarczającą przewagą nad istniejącymi formatami”. Decyzja wywołała spore poruszenie wśród deweloperów, tym większe, że w tym samym czasie Apple poszło w przeciwną stronę i włączyło JPEG XL domyślnie w Safari 17. Format, który miał być następcą JPEG-a, utknął: żywy w jednej przeglądarce, wygnany z najpopularniejszej.
Zwrot przyszedł dopiero pod koniec 2025 roku. W listopadzie 2025 Chrome ogłosił, że wraca do tematu — z nowym, bezpiecznym pamięciowo dekoderem napisanym w Ruście — powołując się na to, że Safari format wdrożyło, Firefox zmienił stanowisko, a sygnały od deweloperów nie ustawały. Impulsem było też uznanie JPEG XL przez PDF Association za preferowany format HDR w PDF. Dekoder trafił do kodu na początku 2026 roku, a Chrome 145 z lutego 2026 dostarczył go — na razie za flagą. Podobną drogą poszedł Firefox.
Czy JPEG XL jest już gotowy na normalny web
Uczciwa odpowiedź brzmi: jako format dostarczania — jeszcze nie, i to bardziej „nie” niż przy AVIF.
Domyślnie JPEG XL włącza tylko Safari, i to w wersji częściowej — obrazy statyczne, bez animacji i bez progresji. Chrome, Edge i Firefox mają dekoder, ale schowany za flagą, wyłączony u zwykłego użytkownika. W praktyce oznacza to, że Can I Use pokazuje dla JXL kilkanaście procent globalnego wsparcia, ale pełne wsparcie to zero — cała ta liczba to częściowa obsługa w Safari. Nie możesz więc dziś opublikować obrazów wyłącznie w JPEG XL. Fallback przez <picture> jest tu obowiązkowy, nie opcjonalny.
Warto też ostrożnie traktować to, co krąży o przyszłości formatu. Wiele tekstów obiecuje, że Chrome włączy JPEG XL domyślnie w drugiej połowie 2026 i że pokrycie „z dnia na dzień skoczy do 85–90%”. To prognoza, nie fakt — źródła pierwotne nie potwierdzają żadnej konkretnej daty. Kierunek jest obiecujący, ale opieranie na nim decyzji wdrożeniowych dziś byłoby przedwczesne.
Gdzie zaczyna się realny problem
I tu, jak zwykle, kończy się rozmowa o specyfikacji, a zaczyna o codziennej pracy — z tą różnicą, że przy JPEG XL warstwa praktyczna jest wręcz ważniejsza od samego formatu. Bo JPEG XL już teraz ma dwa zastosowania, w których jest bezkonkurencyjny, tylko żadne z nich nie polega na „wrzuceniu go na stronę dla wszystkich”.
Pierwsze to archiwum: bezstratna transkompresja pozwala zmniejszyć całą bibliotekę istniejących JPEG-ów o około 20% bez utraty jakości i z możliwością odtworzenia oryginału. Drugie to progresywne wzbogacanie — podanie JPEG XL użytkownikom Safari, a AVIF albo WebP wszystkim pozostałym, przez <picture> lub negocjację treści po stronie CDN.
To jest dokładnie ta sama zasada, o której mówiła cała nasza seria: nowoczesny web nie polega na wyborze jednego zwycięskiego formatu, tylko na świadomym doborze właściwego narzędzia do właściwej roli. AVIF albo WebP na zdjęcia dostarczane publicznie, SVG na logo i ikony, PNG tam, gdzie potrzebna jest bezstratna przezroczystość, a JPEG XL — na razie — do archiwum i do wzbogacania, nie jako format „na wszystko”. Dokładnie tak podchodzimy do tego w Studio iFOX: każdy obraz dostaje format odpowiedni do swojego zastosowania, podpięty pod wydajność i Core Web Vitals, a nie jeden format wrzucony wszędzie na siłę. A żeby ten dobór dało się wykonać bez tarcia — od eksportu po fallback — powstał ImgOpti v2.
Puenta
JPEG XL to najlepszy format, którego prawie nikt nie może jeszcze podać wszystkim. I właśnie ta sprzeczność jest jego najważniejszą lekcją: o sukcesie formatu nie decyduje specyfikacja — nawet najlepsza w klasie — tylko ekosystem, przeglądarki i narzędzia wokół niego. AVIF wygrał wdrożeniowo mimo słabszych papierów, bo po prostu działał tam, gdzie trzeba. JPEG XL dopiero wraca z wygnania, w które nigdy nie powinien był trafić.
Praktyczny wniosek na dziś jest więc spokojny: obserwuj JPEG XL, przygotuj się na niego tam, gdzie już ma sens — w archiwum i w progresywnym wzbogacaniu — ale utrzymaj AVIF → WebP → JPEG jako swój łańcuch dostarczania, dopóki Chrome nie przełączy flagi na domyślną. I właśnie w tym miejscu, między „format jest genialny” a „format da się wdrożyć”, zaczyna się prawdziwa rozmowa o narzędziach.
