Firefox gaat JPEG XL standaard ondersteunen na eerdere veiligheidszorgen

Mozilla zet de ondersteuning voor het JPEG XL-bestandsformaat standaard aan in Firefox 157. De browser kon al sinds versie 152 JPEG XL-bestanden decoderen, maar gebruikers moesten de ondersteuning wel eerst zelf inschakelen in de Firefox Labs-instellingen.

Wat is JPEG XL?

JPEG XL is een afbeeldingsbestandsformaat, of afbeeldingscodec, voor het comprimeren van afbeeldingen. Een van de voordelen van dit formaat ten opzichte van bijvoorbeeld standaard jpegs is dat afbeeldingsbestanden bij lossless compressie 20 tot 60 procent kleiner zijn.

Het formaat ondersteunt daarnaast zowel lossy als lossless opslag, hdr, transparantie en geanimeerde afbeeldingen. Onder meer Safari, Firefox en Chrome ondersteunen de codec al.

Tweakers interviewde eerder dit jaar Jon Sneyers, een van de grondleggers van het bestandsformaat, over de adoptie van JPEG XL.

Mozilla schrijft dat het JPEG XL-ondersteuning vanaf Firefox 157 standaard wil inschakelen voor alle platforms. Deze versie van de browser komt naar verwachting eind september beschikbaar.

Mozilla experimenteert al sinds 2021 met de implementatie van JPEG XL. Volgens het bedrijf vormde het bestandsformaat eerst nog een te groot veiligheidsrisico. Er moest veel code voor de nieuwe codec worden toegevoegd aan de browser. Daar kunnen bugs in zitten die een kwetsbaarheid veroorzaken.

Onlangs kwamen onderzoekers van Google met de op Rust gebaseerde decoder jxl-rs. Die is volgens Mozilla 'veilig en compact' en presteert goed. Daardoor is het volgens Mozilla nu verantwoord om JPEG XL volledig te ondersteunen.

Een voordeel van JPEG XL is de ondersteuning voor progressief laden. Daardoor is op webpagina's al snel een lagekwaliteitversie van de afbeelding te zien. De beeldkwaliteit neemt toe naarmate er meer data wordt geladen.

Reacties (42)

[Navi]

Progressief laden kon een normale JPEG ook gewoon al tientallen jaren toch?

[gitaarwerk]

Yep. Bijna zo oud als het internet. Progressive JPEG is vaak vergeten; Ooit bij een grote coole blauwe winkel geimplementeerd voor CDN. En dat scheelde enorm veel laadtijd + voorkwam flash of unstyled content. Geen JS truukjes (want ook dat kost performance). En voor merendeel van de afbeeldingen was progressive JPG primadebima. JPEG XL is wel stukken beter. Er waren wat andere bestandsformaten, maar hebben ieder nog wel wat issues mee. Zoals WebP nog wat beveilingslekken had. JPEG is ook niet altijd zuiver geweest, maar dat is al langer opgelost. Nog even kat uit de boom kijken met JPEG XL, maar lijkt een beter alternatief dan JPEG 2000. Wordt alleen nog niet op Android ondersteund, dus voor apps zal het nog even op zich moeten laten wachten.

PS; JPEG XL heeft ook mogelijkheid tot alpha channels, dus als je fotos niet zo zuiver als een PNG moeten zijn, dan is JPEG XL een prima alternatief.

[Reactie gewijzigd door gitaarwerk op 25 augustus 2026 10:17]

[tweazer]

Yep. Bijna zo oud als het internet. Progressive JPEG is vaak vergeten;

Ik meen dat het eerder een rechten/licentie probleem was dat men op gif89a en soortgelijk was blijven steken in die tijd ...

[Riddle007]

JPEG XL ondersteunt ook gewoon lossless compressie en dat met bestanden die 30% kleiner zijn dan PNG, dus waarom zou je ooit nog PNG voor web gebruiken eens de ondersteuning breed genoeg is?

[gitaarwerk]

Lijkt mij een prima vraag; Ik heb er nog niet echt mee gewerkt (nu ook nog geen reden toe). Maar ik kijk er naar uit wanneer de ondersteuning breder is.

[Cerberus_tm]

Hmm ik vind professief laden eerlijk gezegd meestal irritant: ik ben dan een foto nauwkeurig aan het bestuderen, denkende dat hij gewoon van lage kwaliteit is; en wanneer hij dan scherper wordt moet ik weer opnieuw beginnen met bestuderen. Of ik heb het tab al lang gesloten. Bij progressief laden zou ik dan wel heel graag een indicator willen zien dat hij nog niet klaar is.

[gitaarwerk]

Kan me dat wel voorstellen. Ik vraag me dan wel af in hoeveel gevallen dit echt zo is? Geen judgement, maar vooral, wanneer gebeurt dit? met glasvezel heb je een afbeelding snel binnen, op mobiel wellicht niet. Ik vind zelf de verschillen wel heel groot om te merken dat de afbeelding nog aan het laden is. Ik ben oprecht benieuwd wanneer je dit ervaart.

[Cerberus_tm]

Ik merk het niet vaak, ik denk omdat websites het meestal niet ondersteunen? Maar het zal inderdaad gebeuren bij heel grote foto's (b.v. een van tientallen MB) of op mobiel? Ik weet het niet zo goed.

[Ilmar]

Het is vooral dat JPEG XL een aantal voordelen van modernere formaten brengt (betere compressie, transparantie, HDR ondersteuning, lossless compressie, minimaal kwaliteitsverlies bij hercoderen etc.) en daarnáást ook progressief kan laden.

Eigenlijk biedt het alle moderne features in één formaat - geen daarvan is op zichzelf nieuw, maar er is geen alternatief dat ze allemaal bij elkaar brengt. En dus eindelijk een modern plaatjesformaat dat een goede 'standaard-oplossing' in eigenlijk alle situaties is.

[pbruins84]

Volgens mij kan JPEG XL al een stuk eerder iets tonen, en wordt de afbeelding scherper in kleinere stapjes dan bij JPEG.

[Hace]

Correct. Standaard JPG kan ook al progressief laden. Het interessante is dat dit ook een klein voordeel geeft voor de compressiefactor. Dus een iets kleiner bestand of iets minder data overdracht.

[Sebastian1313]

Zeker, maar die is niet waar JPG XL haar voordeel mee haalt. Eigenlijk is dat het meest oninteressante van JPG XL.

[GarBaGe]

In Rust (mits je geen unsafe gebruikt) ben je standaard beschermd tegen geheugen lekken, zoals bufferoverflows
Edit: het is niet voor niks dat Rust nu ook in de Linux kernel wordt gebruikt.

[Reactie gewijzigd door GarBaGe op 25 augustus 2026 09:17]

[Oon]

Ik vind het ergens wel eng dat Rust zo langzaamaan de wereld overneemt. Supermooie programmeertaal en naast dat het heel snel is ook enorm krachtig, en ik vind het dan weer heel fijn dat we hiermee weg gaan van het in verhouding enorm trage Python (die vooral populair is door het gemak) dat bijna overal in zit, maar als er nu een keer een issue is in het nog vrij jonge en explosief gegroeide Rust is dat wel meteen een enorm issue.

[GarBaGe]

Waarom vind je het "eng"?
Rust bestaat ondertussen 20 jaar, is initieel begonnen door Mozilla en wordt nu beheerd door de onafhankelijke non-profit organisatie Rust Foundation.
Het wordt tijd om klassiekere talen zoals C en C++ te moderniseren en veiliger te maken.
Rust is hier een hele goede kandidaat voor.
Rust heeft goede interoperabiliteit met C en C++ dus je kan makkelijk bestaande ecosystemen langzaam migreren.

[Bedge85]

Klopt het ook dat rust voor minder goed beschikbaar is voor exotische platforms, zoals bepaalde chip architecturen of bepaalde besturingssystemen (denk aan FreeBSD, OpenBSD, of bepaalde embedded systemen).

[JonKoops]

Rust is ondertussen gewoon een volwassen taal hoor, dus die zorgen lijken me ongegrond. En je kan die stelling ook omdraaien; het lijkt me een enorm issue om bestaande talen zoals C waar je van weet dat het niet echt veilig te maken is, te blijven gebruiken. Tevens worden gaten in de compiler over het algemeen veel serieuzer genomen in de Rust community dan bij C, die vol met undefined behaviour zit.

Overigens is Rust geen vervanging van Python; het is geen dynamische taal met een garbage collector. Het is eerder een vervanging van C/C++.

[xorpd]

Undefined behavior in C is overigens een feature, geen bug. Het zorgt voor het absolute minimum aan overhead en een 1:1 correlatie tussen code en machinetaal. Nodig voor als je programmeert op bare metal, kernel en drivers dus. Geen kernel Rust zonder unsafe dus.

[JonKoops]

Met Rust weet je welk deel van de code unsafe is en met C is het bij default allemaal unsafe, dus dat is wat mij betreft een drogredenatie.

Overigens is undefined behavior helemaal geen ‘feature’ van C, dat zijn gewoon gaten in gedrag tussen verschillende compilers en de specificaties/verwacht gedrag . Je verwart het wellicht met dingen die intentioneel zijn zoals dat je je eigen geheugen moet beheren, waardoor je er directer en soms meer low controle hebt. Dat is gewoon de meest snelle (compilatie) manier om op machinecode te zitten die nog steeds heel portable is, dat is precies waar C voor gemaakt was.

99% van de tijd heb je deze features helemaal niet nodig, en is het dus juist gevaarlijk om te gebruiken, dus dan is voor een systeem op schaal (bijv. de Linux kernel) het juist fijn om alles in een memory safe taal te doen, en dan terug te vallen op handgeschreven memory management of assembly instructies waar het baat heeft.

[Reactie gewijzigd door JonKoops op 26 augustus 2026 10:20]

[xorpd]

Je verwart unspecified behavior met undefined behavior. Laten we index out of bounds als voorbeeld nemen. In Java is dat defined behavior, een index out of bounds genereert namelijk altijd een exception. Hiervoor is het noodzakelijk een compare te doen op de index. In C is dit undefined behavior, waardoor de compiler niet hoeft te checken op de index. Dat is niet alleen sneller maar soms zelfs noodzakelijk. Het maakt ook constructies als array[-1] mogelijk.

[Alienus]

Rust is an sich geen garantie op veilige code, in de kernel moet men af en toe noodgedwongen unsafe blocks gebruiken. Het is discutabel of het dus altijd wel nuttig is om Rust te gebruiken, maar fijn dat er in ieder geval een gedeelte van code wél safe is.

Overigens heeft gebruik van unsafe in rust in de kernal al geleid tot minstens Eén CVE in Rust code zo meldde Greg Kroah-Hartman, één van de lead devs van de Linux kernel, hijzelf zegt dan ook terecht dat het géén silver bullet is.

[JonKoops]

Je krijgt met Rust alsnog veel veiligere en traceerbare code voor de rest van je programma, dat is totaal niet discutabel . Dat er dan een paar unsafe blokken in staan betekent dat je weet waar de gaten zitten en waar je voorzichtig moet zijn en auditen.

Overigens is dat Phoronix artikel smaakmakerij, check de comments en Greg’s eigen e-mail maar eens. Daar is namelijk vrij duidelijk te vinden dat dit een ‘unsafe’ Rust abstractie betreft, waar al een plan ligt om het naar een veilige versie te porten.

[Dlsruptor]

Goed! Want ik zet al mijn RAW bestanden altijd naar JPEG XL.

[fenrirs]

Waarmee je jezelf dus de mogelijkheid ontneemt voor toekomstige verbeteringen in Raw bewerking.

Dat dit niet hypothetisch is bleek bij het opruimen van mijn fotobibliotheek. Eén van mijn favoriete foto’s uit 2007 had ik gelukkig nog in raw formaat.

Een moderne raw converter (darktable 5.7 nightly) gaf zichtbaar betere resultaten dan de oude, Lightroom uit 2007. Betere kleurscheiding en scherpere details door het gebruik van capture sharpening. Lightroom had destijds geen fatsoenlijke lens correctie voor de gebruikte lens. Lensfun heeft deze wel, dus ook daar een verbetering. Een nieuwe print met frisse kleuren hangt inmiddels in de fotogalerij van een verzorgingshuis.

Een andere favoriet had ik destijds gemaakt in Burgers Zoo op ISO 1600, met mijn D50. Veel ruis, maar een hele fijne foto. Ook hier kon ik meer uithalen met Rawforge in combinatie met Darktable.

Daarom bewaar ik toch liever de Raw bestanden.

maar goed, voor gewone niet bijzondere snaps JpegXL een prima vervanging van jpg/avif

[BleghBlarg]

Gewoon uit interesse, verwacht je dat de progressie van fotobewerking nog zoveel stappen gaat nemen die het resultaat echt zichtbaar verbeteren?

Zelf ben ik te blind om dit te kunnen waarderen maar ik kan me met de technologische vooruitgang vanaf 2007 er iets bij voorstellen dat het nu beter is maar ik twijfel sterk of daar nog veel uit te persen valt. Vooral omdat fotobewerking doormiddel van gespecialiseerde lightroom-ish-AI die verandering ook teweeg kan brengen zonder het RAW bestand lijkt me.

[fenrirs]

Veel verbetering zal er inderdaad niet meer in zitten. Je bent beperkt door fysieke zaken. AI kan wel wat toevoegen, maar niet eindeloos

[Stupidsimple]

Ja inderdaad, werd vroeger vooral veel gebruikt (of toen zag ik het vaker door de langzame internetverbindingen van die tijd).

JPEG XL heeft nog wel wat meer opties voor progressief laden, sneller te zien (al bij 1%), en meer gradaties in het laden.

[harakiri576]

Tja, we leven ook niet in modem tijdperk meer. De gebruikswaarde ervan is twijfelachtig.

"too little, too late"

[divvid]

door de foto biblitotheek van een interne app om te zetten naar jpegxl konden we een paar TB aan data besparen. Omdat dat spul intern op een vrij dure share stond (IT rekent EUR279/TB) leverde dat dus nog iets op.

[Caelorum]

In ons hoogontwikkeld stukje van de wereld wel ja. Mensen in Syrië, Afghanistan, verafgelegen gebieden in Kenia, etc. zullen het denk ik wat meer kunnen waarderen.
Zeker mobiel is in de wat meer van de bewoonde wereld afgelegen gebieden niet vanzelfsprekend snel en Starlink en dergelijke zijn ook niet altijd een haalbaar alternatief.

[Cid Highwind]

Zo ver hoef je het niet te zoeken. Zodra je de oostgrens over bent, buiten het bereik van de Nederlandse masten, ligt er een derde wereld voor je open op dit vlak

[Mextreme]

Hoe efficiënter je datatransport, des te minder energieverbruik, denk ik dan... Of zit ik daar naast?

[Ghoelian]

Het is tegenwoordig nog steeds goed om je website zo klein mogelijk te houden hoor. Je kunt echt best goed verschil merken tussen een website die puur html en wat thumbnails laadt, dan eentje die tal javascript bestanden moet downloaden om de afbeelding op het goeie formaat te krijgen. Vooral als je op mobiel internet zit of een wat ouder apparaat gebruikt.

Mijn eigen website gebruikt alleen kleine thumbnails op de overzichtpagina's, en alle afbeeldingen zijn in zowel jpeg xl, webp, als standaard jpeg beschikbaar. Dan kan je browser gewoon zelf kiezen welke die wil hebben. Kost wel wat extra schijfruimte omdat ik nu 2 (thumbnail + origineel) * 3 (jpeg xl, webp, jpeg) = 6 bestanden per afbeelding nodig heb. Misschien dat de jpeg (xl) versies nog wat meer efficient kunnen, daar zit een lagere resolutie al in het bestand gebakken, maar weet niet of dat goed genoeg is voor een thumbnail.

[William_H]

In Nederland misschien. Maar er zijn veel landen waar er geen Gigabit verbindingen liggen.

[Aganim]

Afgelopen weekend ben ik in de binnenlanden van Noord-Frankrijk geweest. Ik kan je vertellen dat progressief laden op een mobiele verbinding daar zeer gewenst is, met regelmaat kwam ik daar niet verder dan EDGE, dus nog niet eens een 3g verbinding. We zijn verwend in Nederland en vergeten daardoor makkelijk dat het lang niet overal zo super geregeld is met internet.

[Killemov]

Wat wordt de te gebruiken bestandsextensie hievan? JXL ?

[Alex3]

Wikipedia: JPEG XL

[CharlesND]

Wat wordt de te gebruiken bestandsextensie hievan? JXL ?

Affinity Photo schrijft ze weg als .jxl files. Dezelfde extensie wordt ook door ChatGPT gemeld. Of het nu ook de officieel door allerlei internationale commissies vastgestelde extensie is zou ik niet weten...Misschien bestaat die nog niet?

[Maurits van Baerle]

Het JPEG XL formaat bestaat al een paar jaar en .jxl is al jaren de standaard extensie voor JPEG XL. Zo doen Safari, en Affinity, en Photoshop, en macOS en iOS etc. het al tijden. Het zijn de browsers die een beetje achterlopen.

[Globefrotter]

Fijn dat Firefox standaard jpg xl gaat ondersteunen. Misschien draagt dat bij om het jpg xl bestand meer mainstream te maken, want het formaat verdient het.
Sinds een aantal jaren zet ik al mijn foto's op mijn iPad, als vervanging van fotoalbums.
Ik zet al mijn RAW foto's die ik met mijn Canon R5-2 maak, om naar jpg xl én jpg, omdat de site van bijv. Marktplaats (nog?) geen jpg xl ondersteund. Meer sites verlangen jpg, helaas.
Zodoende zie ik dat jpg xl bestanden zo'n 30 tot 35% kleiner dan 'gewoon' jpg zijn bij een echt hogere kwaliteit!

Reden genoeg dus om dit formaat te omarmen......

[Reactie gewijzigd door Globefrotter op 25 augustus 2026 12:38]

[ArmEagle]

Ondersteunt Chrome JPEG XL al - zoals benoemd in de uitgelichte sectie?

De auteur van het gelinkte artikel schrijft zelf en verwijst naar de intent to ship status van de Blink render engine van Chrome/ium.
Op dat item is te lezen dat de functionaliteit nog achter een flag zit. Dan vind ik 'ondersteunen' een te hoge verwachting geven.

[Maurits van Baerle]

Op dit moment geldt voor Chrome en Firefox hetzelfde: ondersteuning zit er in maar je moet het aan zetten want het is nog experimenteel.

Nu heeft Mozilla een moment gegeven dat het standaard aan zal staan en Chrome zal waarschijnlijk snel volgen.

Safari ondersteunt het al lang dus waarschijnlijk voor het eind van het jaar kunnen de meeste mensen gewoon JPEG XL zien.