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 (20)

[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 ...

[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.

[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"

[Killemov]

Wat wordt de te gebruiken bestandsextensie hievan? JXL ?

[Alex3]

Wikipedia: JPEG 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]

[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.

[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++.