Chrome 155, vydaný 6. října, už obrázky JPEG XL zobrazí bez zapínání experimentální podpory. Formát se vrací čtyři roky poté, co Google oznámil jeho odstranění z prohlížeče, tentokrát s dekodérem v Rustu. Využití najde hlavně u velkých fotografií, bezeztrátové grafiky a archivů starých JPEGů. AVIF kvůli němu ale opouštět nemusíte.

Na konci října 2022 zdůvodnil Google odstranění JPEG XL nedostatečným zájmem a malým přínosem proti existujícím formátům. Kód zmizel z Chromu 110. JPEG XL si mezitím našel místo v grafických editorech a v systémech Applu včetně Safari, bez Chromu ale na webu zůstával okrajovou záležitostí.

V úterý 6. října oznámil Google návrat podpory JPEG XL. Zároveň doporučil vývojářům zkoušet AVIF i JPEG XL: každý se hodí pro jiné obrázky a požadavky.

Proč Chrome odmítl formát, jehož přednosti znal

Chrome s JPEG XL experimentoval od roku 2021. Už tehdy Google zmiňoval lepší kompresi než JPEG, bezeztrátový režim, HDR, průhlednost, animace, progresivní dekódování i schopnost přebalit existující JPEG bez další ztráty. Přednosti tedy znal, podporu však ponechal jen jako experiment, který si uživatel musel sám zapnout.

Při rozhodování o další podpoře Google porovnával přínosy s náklady. Jim Bankoski z Googlu v diskusi vývojářů Blinku popsal, podle čeho tým rozhodoval: účinnosti komprese, rychlosti kódování a dekódování, možností stávajících formátů a podpory v dalších prohlížečích a systémech. Připomněl také, že peněžní i hardwarové náklady nesou partneři mimo Google. Chrome by JPEG XL musel dlouhodobě udržovat vedle JPEG, PNG, WebP a AVIF, přestože jej tehdy ve stabilní verzi nepodporoval žádný jiný velký prohlížeč.

Bezpečnost mezi vyjmenovanými důvody nebyla. Obavy z ní ale měla Mozilla. Firefox s formátem také experimentoval od roku 2021, jenže referenční dekodér představoval zhruba sto tisíc řádků vícevláknového C++. Mozilla nechtěla do prohlížeče přidat tolik nového kódu, který zpracovává data z internetu.

Rust jako vstupenka

Mozilla proto podmínila nasazení JPEG XL novým dekodérem. Vyzvala tým v Google Research, aby vytvořil rychlou, kompaktní a kompatibilní implementaci v Rustu. Vznikl jxl-rs. Dekodér, který nakonec umožnil návrat JPEG XL do Chromu, tak napsali lidé z Googlu na popud konkurenčního prohlížeče.

V listopadu 2025 tým Chromu svůj postoj veřejně přehodnotil. Rick Byers připomněl, že Safari už JPEG XL podporuje, Firefox změnil postoj a vývojáři o formát dál žádají v bug trackeru, průzkumech i projektu Interop. Chrome proto přijal možnost zapojit výkonný a paměťově bezpečný dekodér, pro zapnutí podpory všem uživatelům ale požadoval také závazek dlouhodobé údržby.

Kód se do Chromia vrátil v lednu 2026 a Chrome 145 ho od února nabízel pod příznakem chrome://flags/#enable-jxl-image-format. K integraci i samotnému jxl-rs podstatně přispěl externí vývojář Helmut Januschka. V srpnu Mozilla i Google oznámily záměr podporu zapnout a v říjnu ji Chrome 155 zpřístupnil bez příznaku.

Proč tolik záleží na jazyku dekodéru

Obrazový dekodér zpracovává složitá binární data z libovolného webu. Chyby v práci s pamětí, například čtení mimo hranice bufferu nebo použití už uvolněné paměti, z něj mohou udělat bezpečnostní slabinu. Sandbox je další vrstva obrany; bezpečný Rust těmto chybám brání už při překladu nebo je zastaví kontrolou za běhu.

Bezpečnost ale nesměla výrazně zpomalit vykreslování. Vývojáři proto museli zachovat výkon SIMD instrukcí, které zpracovávají více dat současně. Většina jxl-rs používá bezpečný Rust, zbývající bloky unsafe vyžadují zvláštní kontrolu. Výsledný dekodér se rychlostí přibližuje referenční implementaci v C++, takže jeho nasazení nevyžaduje výrazný ústupek ve výkonu.

Kde JPEG XL vyhrává a kde ne

Google uvádí o 30 až 50 procent lepší kompresi než u JPEG. Pro vývojáře, který už používá AVIF nebo WebP, ale tohle srovnání nestačí.

Mozilla zveřejnila porovnání fotografie a screenshotu při stejném skóre metriky SSIMULACRA 2. Ta odhaduje, jak velký rozdíl proti originálu uvidí člověk. Shodné skóre tak umožňuje porovnat velikosti souborů při přibližně stejné viditelné kvalitě.

Ve ztrátovém režimu byl u obou obrázků nejmenší AVIF. Jakmile ale musel obraz zůstat přesný pixel po pixelu, pořadí se otočilo. Bezeztrátový JPEG XL u screenshotu ušetřil proti AVIF přes 40 procent dat, proti bezeztrátovému WebP však jen několik procent.

Dva obrázky nejsou benchmark celého webu. Cloudinary, která se na vývoji JPEG XL podílela, v roce 2023 na své sadě naměřila při ztrátové kompresi naopak náskok JPEG XL před AVIF zhruba o pět až deset procent.

Obrázek, který je vidět dřív, než se stáhne

JPEG XL má vedle komprese ještě jednu výhodu: při progresivním vykreslování se obraz zpřesňuje během stahování. Na 135kB fotografii spící lišky, kterou zveřejnila Mozilla, je po stažení patnácti procent dat už rozeznatelný námět, v polovině je obraz zřetelný, jen ještě nemá plné rozlišení. AVIF podle Mozilly nabízí jen základní formu průběžného vykreslování.

U miniatury se rozdíl sotva projeví. U velké fotografie v galerii nebo přes celou obrazovku už může na pomalém připojení rozhodnout, jestli návštěvník vidí rozpoznatelnou fotku, nebo čeká před prázdným místem. O něco větší JPEG XL tak může působit rychleji než menší AVIF. Safari ovšem progresivní vykreslování JPEG XL nepodporuje, takže tam tato výhoda odpadá.

Staré JPEGy menší, a přitom stejné

JPEG XL umí také uložit data hotového JPEGu úsporněji bez další ztrátové komprese. Obraz zůstane stejný a původní JPEG lze obnovit bajt po bajtu. Kvalitu, kterou JPEG kdysi zahodil, to nevrátí, ale nic dalšího neubere. Autoři formátu uvádějí typickou úsporu kolem 22 procent, u jednotlivých souborů se výsledek liší.

Pro archiv fotografií nebo e-shop s tisíci produktových snímků to znamená možnost zmenšit soubory bez další ztráty kvality. Server může skladovat JPEG XL, podporovaným prohlížečům ho posílat přímo a pro ostatní zrekonstruovat původní JPEG.

Kdy JPEG XL nasadit vedle AVIF a WebP

Podpora zatím není všude stejná. Chrome 155 ji má zapnutou, Safari má omezení popsané výše a Mozilla posunula plánované zapnutí podpory na Firefox 158. Kvůli starším prohlížečům je stále potřeba záložní varianta; samotný soubor .jxl v <img> nestačí.

U běžných fotografií ve webové kvalitě zůstává AVIF dobrým výchozím formátem. V příkladech Mozilly vytvořil menší soubory, takže pokud jej už generujete, není důvod ho plošně nahrazovat. U velkých snímků stojí za porovnání i JPEG XL, protože průběžné vykreslování může větší soubor vyvážit.

Pro bezeztrátovou grafiku má smysl porovnat JPEG XL s WebP. Samotné ostré hrany nebo text však ještě neznamenají, že bezeztrátový režim potřebujete: screenshot v tabulce má ve ztrátovém AVIF při velmi vysoké kvalitě 11,6 kB, v bezeztrátovém JPEG XL 92 kB. Loga a ikony dostupné ve vektorové podobě dál ponechte v SVG.

Vedle velikosti záleží i na rychlosti dekódování. Sergey Davidoff v diskusi vývojářů Firefoxu po opravě svého měření uvedl, že se mu bezeztrátový JPEG XL dekódoval patnáctkrát až dvacetkrát pomaleji než WebP při úspoře přibližně desetiny dat. Jde o jeden test konkrétního obrázku, přesto je to důvod měřit i čas dekódování na cílových zařízeních.

WebP se hodí také jako záloha pro klienty bez podpory AVIF a JPEG XL. Do stávajícího zpracování obrázků tedy stačí přidat JPEG XL tam, kde přinese měřitelný užitek.

Pořadí v <picture> je výsledek benchmarku

Element picture umožňuje nabídnout více variant. Prohlížeč prochází elementy <source> odshora, přeskočí nepodporované formáty a použije první vyhovující zdroj. Pokud žádný nenajde, použije <img>. Pro responzivní obrázky doplníte varianty v srcset a odpovídající sizes.

<picture>
  <source srcset="letna-2400.jxl" type="image/jxl">
  <source srcset="letna-2400.avif" type="image/avif">
  <img src="letna-2400.jpg" width="2400" height="1600"
       alt="Pohled na Prahu z Letenské pláně">
</picture>
Code language: HTML, XML (xml)

Tento zápis upřednostní JPEG XL, i kdyby byl AVIF menší. Prohlížeč velikosti souborů neporovnává. U velké galerijní fotografie můžete dát přednost progresivnímu JPEG XL, u produktového náhledu menšímu AVIF. Pořadí elementů <source> je zapsaný výsledek vašeho měření, ne žebříček novosti.

Porovnávejte reprezentativní sadu vlastních obrázků při stejné vizuální kvalitě. Hodnota quality 80 znamená v různých enkodérech něco jiného; shodné skóre SSIMULACRA 2 je užitečnější vodítko. Fotografie, screenshoty a průhlednou grafiku vyhodnocujte odděleně. Pokud obrázky kóduje CDN za běhu, započítejte i čas kódování.

Návrat JPEG XL rozšiřuje možnosti hlavně tam, kde samotná velikost ztrátově komprimovaného souboru nestačí: u postupného načítání velkých fotografií, zachování každého pixelu nebo zmenšení starých JPEGů. Pokud vám u ostatních obrázků AVIF vychází lépe, není důvod ho nahrazovat.