Google zet ondersteuning voor JPEG XL aan in Chrome 155

Google zet de ondersteuning voor het beeldformaat JPEG XL aan in versie 155 van zijn Chrome-browser. Deze functionaliteit was al sinds versie 145 aanwezig, maar gebruikers moesten die zelf activeren in de instellingen. JPEG XL biedt 30 tot 50 procent betere compressie dan JPEG, meldt Google.

De ontwikkelaars achter deze vernieuwing in Chrome adviseren fotografen en webontwikkelaars om zowel AVIF als JPEG XL te gebruiken. Ze verwachten dat het laatstgenoemde beeldformaat het beste is voor compressie van afbeeldingen waarbij detail van groot belang is. Dit geldt bijvoorbeeld voor foto's, maar ook voor afbeeldingen waarbij fijnkorrelige decodering en daarmee geleidelijk laden gewenst zijn.

Geschreven in Rust

Google heeft de functie geschreven in de op veiligheid gerichte programmeertaal Rust. In hun blogpost zetten de ontwikkelaars van Chrome uiteen hoe ze ondersteuning voor JPEG XL hebben toegevoegd en hoe ze de prestaties van de beelddecodering hebben verbeterd. Voor interoperabiliteit tussen verschillende browsers hebben de ontwikkelaars meegedaan aan de Interop 2026 JPEG XL Investigation. De daarin opgenomen tests voor JPEG XL-ondersteuning werken in Chrome.

JPEG XL, beelddecodering. Bron: Google

Reacties (20)

[Maurits van Baerle]

Eindelijk. Wij hielden het een beetje in de gaten omdat we een keuze moesten maken voor een beeldformaat voor een nieuwe dienst. Het werd JPEG XL met WebP als fallback omdat duidelijk werd dat JPEG XL ondersteuning op tijd voldoende gevorderd zou zijn, ruim voordat wij live gaan.

Gisteren Chrome, volgende week Firefox, en zoals het er nu naar uitziet (omdat de meeste browsers ofwel op Chromium ofwel op Firefox zijn gebaseerd, Safari ondersteunt het al jaren) zijn er eind deze maand amper nog browsers over waar de nieuwste versie het niet ondersteunt. Dan is het alleen nog een kwestie van de massa die de updates naar de nieuwste versies moet krijgen, maar dat gaat tegenwoordig erg snel.

[Reactie gewijzigd door Maurits van Baerle op 7 oktober 2026 17:28]

[JonKoops]

Wat is voor jullie het voordeel van JPEX XL over WebP? Waarom geen AVIF?

[Maurits van Baerle]

De keuze voor JPEG XL als primair formaat met WebP als fallback is heel simpel. Op alles behalve één punt is JPEG XL beter dan WebP. Het enige waar WebP beter in is is de ondersteuning. WebP is een flink stuk ouder dus vrijwel iedere browser, zelfs op oude smartphones, kan WebP weergeven. Dat maakt het een goede fallback voor als iemands browser nog geen JPEG XL ondersteunt.

AVIF en JPEG XL liggen veel dichter bij elkaar qua functies en kwaliteit dus die keuze was moeilijker. Wij gaan het gebruiken voor hoge kwaliteitsfoto’s en dan helpt het dat JPEG XL écht een fotografieformaat is. Dat zie je aan de krankzinnige resoluties (een miljard x een miljard pixels) en kleurdieptes (32 bits) die je er in kunt stoppen. AVIF is dan meer een formaat uit de computer hoek waarbij er gekozen is voor beperkingen die goed genoeg zijn om iets op een computerscherm af te beelden.

[Reactie gewijzigd door Maurits van Baerle op 7 oktober 2026 19:22]

[pinballmachine]

Het klinkt alsof beeldkwaliteit belangrijk is voor je nieuwe project. Waarschijnlijk heb je je al verdiept in WebP, maar zo niet, dan geef ik je graag twee vrijblijvende tips:
1. Gebruik altijd de optie -sharp_yuv tijdens het encoden.
2. Gebruik de referentie-encoder cwebp i.p.v. ImageMagick voor het encoden.

ImageMagick zou in theorie precies dezelfde WebP's moeten kunnen genereren als cwebp, maar mij is het nooit gelukt om met ImageMagick dezelfde beeldkwaliteit en constante compressie te halen. Soms worden ze kleiner, soms groter, maar steevast zien ze er lelijker uit via ImageMagick dan via cwebp.

Ik ben zelf erg gecharmeerd van de beeldkwaliteit die AVIF biedt, zeker voor fotografie. Grappig genoeg vind ik de vergelijking met de kip op jpegxl.info net in het voordeel uitvallen van AVIF, al zijn de verschillen superklein. Als je dat naast elkaar ziet, is er weinig reden om voor JPEG XL te kiezen. Daarom gaat voorlopig mijn voorkeur nog uit naar AVIF vanwege bredere ondersteuning. Volgens mij kun je best wegkomen zonder fallback vandaag de dag, met AVIF.

[Maurits van Baerle]

Dank voor de tip! Ik heb het toegevoegd aan de ticket. Wij zijn nog niet aan testen met WebP toegekomen, dat komt pas als we de laatste stukjes van de website doen, eerst de backend goed ingericht krijgen.

De reden om uiteindelijk voor JPEG XL te gaan en niet voor AVIF heeft te maken met het proces aan de achterkant. Wij hebben geen invloed op wat voor bronmateriaal we aangeleverd krijgen. Dat kan ouderwetse JPG zijn maar ook TIFF, of HEIC, of AVIF, of BMP, of PNG of wat dan ook. Sommige afbeeldingen kunnen misschien 30000 x 20000 pixels HDR zijn.

Omdat het gekkenwerk is om met zoveel formaten rekening te moeten houden gaan we direct bij binnenkomst alles converteren naar lossless JPEG XL. Er is geen enkel formaat dat dingen kan die JPEG XL niet kan dus kan dat zonder informatieverlies gebeuren. Vanaf dat moment hoeven we alleen met JPEG XL rekening te houden, als 'originelen' in een soort archief, en kunnen we dat gebruiken om te converteren naar lossy JPEG XL in normale afmetingen om te gebruiken aan de voorkant (plus een WebP voor oude browsers).

Als we voor AVIF hadden gekozen dan zouden we een afbeelding van 30000 x 20000 eerst moeten verkleinen tot iets wat in AVIF past en zouden we daar dus informatieverlies hebben.

Ik verwacht dat de JPEG XL encoders nog jaren verbeteringen gaan zien dus misschien dat we over een paar jaar die ‘originele’ JPEG XLs nog een keer converteren naar een nieuwere versie van de frontend bestanden.

[Reactie gewijzigd door Maurits van Baerle op 7 oktober 2026 23:00]

[smiba]

Het coole is ook nog eens aan JPEG XL, is dat je zonder kwaliteitsverlies het omkan zetten van JPEG naar JPEG XL, maar wel een kleiner bestand overhoud!

Alleen dat al zou het veel sterker dan AVIF maken, gezien zo veel user content simpelweg als JPG geüpload word. Natuurlijk zodra je resized, of verder wil comprimeren verlies je wel extra kwaliteit, maar zou zouden bestaande websites direct bandbreedte kunnen besparen door hun JPGs als JPEG XL te serveren

[Maurits van Baerle]

Inderdaad, je kunt de JPEG XL encoder met lossless JPEG transcoding een JPEG laten herindelen naar JPEG XL zodat hij bestaande JPEG data efficiënter inpakt en hij zo’n 20% kleiner wordt zonder kwaliteitsverlies. Het mooiste is dat je diezelfde data ook weer terug kan brengen naar een ouderwetse JPEG en hij dan bit voor bit identiek is aan het origineel.

Wij hebben ons daar verder niet in verdiept omdat het (zo klein mogelijk of terug converteren naar JPEG) voor onze toepassing niet relevant is maar ik heb me wel eens afgevraagd wat het kwaliteitsverschil is tussen transcoden voor 20% ruimtewinst en het converteren van JPEG naar een bitmap en die dan laten encoden door JPEG XL. Dat laatste lijkt me meer ruimtewinst op te leveren en misschien niet of nauwelijks kwaliteitsverlies omdat JPEG XL zoveel betere kwaliteit is dan JPEG.

[vickypollard]

Wij gebruiken op onze websites sinds een paar maanden AVIF en dat gaat eigenlijk op elk device wel prima. Ook het downloaden en bekijken van een afbeelding kan praktisch altijd voor gebruikers. De grootste problemen zijn vooral dat mensen het irritant lijken te vinden dat het geen JPEG is als ze een afbeelding downloaden, want dat is wat ze kennen. Daarnaast nog dat een aantal platforms geen correcte previews genereert van AVIFs als je een URL deelt, bijvoorbeeld op LinkedIn of in Teams. Of dat ooit gaat komen weet ik niet, want ze lijken er niet happig op. We gaan voor die og:image nog maar terugvallen op een JPEG-versie.

[Reactie gewijzigd door vickypollard op 7 oktober 2026 20:53]

[maykoga]

Progressief laden: JPEG XL-afbeeldingen laden vloeiend in lagen (eerst wazig, daarna scherp).

WebP laadt van boven naar beneden, wat voor een minder fijne gebruikerservaring zorgt bij tragere verbindingen

en zie het Tweakers achtergrond artikel over JpegXL waarom het superieur is: review: Google is om: waarom JPEG XL alsnog de standaard voor het web wordt

[Reactie gewijzigd door maykoga op 7 oktober 2026 18:00]

[pinballmachine]

AVIF ondersteunt wel degelijk progressief laden. In het begin misschien niet, maar inmiddels al lange tijd wel. In de referentie-encoder (avifenc) kun je --progressive gebruiken hiervoor.

Dit is mogelijk omdat AVIF ook ondersteuning heeft voor meerdere lagen, en er dus een wazige laag met extreem veel compressie eerst getoond kan worden, en daarna pas de laag met minder compressie die er beter uitziet.
Dit staat helaas incorrect in het achtergrondartikel waar je naar linkt.

[PolarBear]

AVIF ondersteunt wel degelijk progressief laden. In het begin misschien niet, maar inmiddels al lange tijd wel. In de referentie-encoder (avifenc) kun je --progressive gebruiken hiervoor.

Maar wordt het ook daadwerkelijk zo geïmplementeerd in de browers/platformen?

[pinballmachine]

In Edge werkt het in ieder geval goed als je zo'n plaatje genereert. Ik ga er vanuit dat dit dus voor alle Chromium-browsers geldt.

In Firefox weet ik het niet. Ik meen me te herinneren dat ik dit wel eens getest had en dat het werkte. Als ik het nu probeer te testen door de verbinding te throttlen in developer mode, werkt het niet goed. Ik krijg dan gewoon de hoge resolutie AVIF te zien en niet eerst de wazige laag. Kan ook zijn dat de throttling in developer mode niet goed genoeg werkt.
Firefox had ook altijd moeite met tiled AVIF's, zoals die bijvoorbeeld uitgespuugd worden door Paint.NET. Misschien is de AVIF support wat basaler in Firefox.

[Bedge85]

Vergeet niet FireFox ESR. Recent is FireFox 153 ESR uitgebracht. En ergens in de tweede helft van 2027 komt de nieuwe FireFox ESR release uit waarin dan ook ondersteuning zit voor jpeg-xl.

[fenrirs]

Nu nog ondersteuning in whatsapp, signal etc. En uiteraard in diverse firmwares van camera’s

Onze wildlife cams zouden er wel bij varen, maar iets zegt me dat dat nog wel even op zich zal laten duren….

[Maurits van Baerle]

Dat is een beetje een asymmetrisch probleem denk ik.

Als je met een mobiele app kunt leunen op WKwebview (iOS) of Webview (Android) dan kun je dat gebruiken voor het decoden van .jxl bestanden.

Het grotere obstakel zal het encoden zijn. Moet Instagram een eigen encoder in hun app stoppen? Moeten ze dat serverside laten doen?

Er zijn wel hele kleine JPEG XL encoders speciaal voor camera’s en dergelijke maar ik vermoed dat die minder efficiënt zullen zijn dan wat Instagram (waar bandbreedte en bestandsgrootte meer doorslag zal geven) zal willen hebben.

[Atomsk]

Wat gaat het Tweakers fotoalbum ondersteunen trouwens? Nu is het nog jpeg-only zo te zien.

[NostraDavid]

Ik zie niet in hoe dit het web beter gaat maken. Mensen optimaliseren hun plaatjes nu al amper, omdat dat iets is wat door Photoshop/Gimp/Paint gedaan zou moeten worden, maar dat gebeurt niet, dus je krijgt straks gewoon kneiter grote JPEG XL plaatjes ipv je standaard JPEG. Nou, wat een vooruitgang...

jpegli moet je zelf compileren, maar doet veel goeds kwa kwaliteit/grootte. Als gebruikersgemak wilt (gewoon je foto op een window slepen) en er voor wilt betalen is er JPEGMini.

edit: voor jpegli zijn de binaries trouwens "cjpegli" (encoder) and "djpegli" (decoder). Oh, en JPEG compressie is altijd lossy, dus maak backups voordat je comprimeert!

Voor PNGs is er oxipng die ook heel goed werkt - let er op dat PNG bekend staat dat compressie geen data weggooit, maar liggend aan de settings, kan oxipng het aantal kleuren reduceren - nu kan de impact van de gereduceerde kleuren gecompenseerd worden met een dithering patroon, en dat kan er erg goed uit zien, maar zeker goed om hier bewust van te zijn.

Vraag je locale LLM voor een plan om dit te kunnen testen zonder data te verliezen

[Reactie gewijzigd door NostraDavid op 8 oktober 2026 11:34]

[Targox]

98.83% van browsers ondersteunen AVIF, 17.39% ondersteunen JXL. Voorlopig dus nog geen reden om dit op te nemen in webdesign werk

[Maurits van Baerle]

Vandaag niet, nee. Maar omdat de meeste browsers tegenwoordig op Chromium of Firefox gebaseerd zijn gaat het ineens erg hard. Volgende maand ziet het er al heel anders uit.

Sinds gisteren ondersteunt Brave ineens JPEG XL, vanaf later vandaag gaat Microsoft Edge ook om als het goed is. Firefox gaat volgende week om, en een hoop Firefox klonen konden niet wachten dus die ondersteunen het nu al.

Vivaldi en Opera gaat waarschijnlijk een paar weken langer duren, en je hebt nog mensen die een ESR gebruiken dus voor hen duurt het misschien nog een maand of twee.

Safari/iOS/macOS ondersteunden het al sinds 2023.

[CrazyJoe]

Vanaf Firefox 157 kun je support voor JPEG XL aanzetten via Settings/Firefox Labs/Web Page Display.

Werkt zo te zien prima!

Het kan zijn dat nog niet alle variaties ondersteund worden, maar de JPEG XL web pagina ziet er prima uit.