Google voegt langverwachte ondersteuning JPEG XL toe aan Chrome

Google heeft ondersteuning voor JPEG XL toegevoegd aan de opensourcecodebase voor Chromium. Daarmee kunnen browsers als Chrome het .jxl-bestandsformaat voortaan verwerken. Google introduceerde en stopte de ondersteuning voor het afbeeldingsformaat in 2022.

Met de commit van JXLImageDecoder voor de codebase voor Chromium kunnen browsers op basis van die engine voortaan JPEG XL-afbeeldingen verwerken. De decoder is gebaseerd op de Rust-gebaseerde decoder jxl-rs. Deze zou vanwege de memory-safe programmeertaal veiliger zijn dan eerdere implementaties van de decoder. De beslissing van Google om JPEG XL weer te ondersteunen komt overigens niet onverwachts. Het bedrijf liet dat eind 2025 al doorschemeren, maar een exacte datum was vooralsnog niet bekend.

Google begon in februari 2022 met de ondersteuning van JPEG XL in Chrome, maar stopte aan het eind van dat jaar de ondersteuning alweer. Er zou niet genoeg interesse in het nieuwe ecosysteem zijn en de afbeeldingscodec zou niet genoeg verbeteringen bevatten vergeleken met bestaande formaten. Daarop was toen al veel kritiek.

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 lossless tussen de 20 en 60 procent kleiner zijn. Het formaat ondersteunt daarnaast zowel lossy als lossless opslag, hdr, transparantie en geanimeerde afbeeldingen. Onder meer Safari en Firefox ondersteunen de codec al.

Reacties (28)

[nicolaasjan]

Werkt al in Chromium Development build 146.0.7634.0

Zit nog wel achter een flag:

chrome://flags/#enable-jxl-image-format ---> Enabled

[michaelboon82]

We hebben nu toch .webp? Dat wordt door alle browsers al jaren ondersteund en Adobe en Microsoft ondersteunen dit formaat. Ik zie het nut van JpegXL niet zo in.

[dipje2]

voor web is webp wel fijn.
maar jpegxl kan een hoop meer / is beter op een aantal fronten.

voor mij:
* jpeg-xl encode aan de hand van een visual-quality metric. Als je een berg plaatjes comprimeert en alles '-d 1.5' meegeeft, komen ze er allemaal uit met dezelfde kwaliteit. Plaatjes die moeilijk comprimeren komen er vanzelf goed uit, waarje bij jpeg / webp / avif aan de crf/kwaliteit instelling moet sleutelen. 'quality 80%' in jpeg is niet hetzelfde voor elk bestand namelijk, met jpeg-xl dus wel
* 4:4:4 support en andere formaten (webp is alleen 4:2:0 geloof ik?)
* webp hoort onder de categorie 'betere compressie maar meer smoothing'. jpeg-xl behoudt structuur, grain en dat soort dingen beter. Voor foto's vind ik het een veel fijnere codec
* 16 bit support, hdr support, etc..

Ik vond https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front een good read. Is wel een beetje 'wij van wc eend' (is geschreven door 1 van de major developers van jpeg-xl en vanuit het bedrijf wat hard er op heft ingezet, maar toch, ze cherry-picken het niet en ze schreeuwen ook niet dat het 100% overal de beste keuze is).

begrijp me niet verkeerd: webp is ook fijn, en juist voor web-based zaken leuk. De support in browsers is ondertussen 100% overal zover ik weet, en met ondersteuning voor lossless, transparantie, animatie, etc.. is het een 'safe' codec om gewoon 'alles' naar te optimizen. Of het nu een PNG is met scherpe transparante randjes, of een gifje met animatie of een jpeg afbeelding.

Maar webp is voor mij al heel lang oud, google is al tijden bezig met een webp2 (maar zit niet veel actie in), en het idee dat 'avif' of 'webp' dus het beste zijn is niet zo.

Dan kan je zeggen 'maar zijn ze niet goed genoeg, waarom weer iets nieuws?!'. En ik - nogal van het niet-stil-zitten-met-verbeteren' vind dat geen argument om maar te stoppen met nieuwe dingen te gebruiken.

MAAR... je kan dan ook zeggen van jpeg.

Juist dingen als 'jpeg li', de compatible jpeg encoder die gebruikt maakt van de analyzes van jpeg-xl scoort bijzonder snel en goed, fixt het 'compressie setting per bestand'-probleem en fixt het 'oversmoothing' probleem van webp.

Dus ehm, ja, ik vind jpeg-xl 'beter' op een hoop fronten en dus de moeite waard om te ondersteunen, en vind het argument 'webp is goed genoeg' dus niet zo van toepassing omdat ik dan nog liever bij png/jpeg (li) wil blijven.

[michaelboon82]

Goede uitleg!

Het gaat in het artikel om de ondersteuning in browsers, dus vandaar mijn reactie waarom er nog een nieuw formaat moest komen als we al een verbetering hebben naar jpg in de vorm van webp. Je bevestigd dat het voor het web een erg geschikt formaat is. Natuurlijk kan het altijd beter...

[_Bob_]

.webp ondersteunt een max resolutie van 16383 x 16383 pixels, wat soms gewoon te weinig is. JPEG XL daarentegen ondersteunt tot 10^12 pixels in totaal, vandaar ook de naam.

Verder is de compressie beter bij JPEG XL, dus ook voor kleine foto's heb je er wat aan doordat ze minder ruimte innemen.

[bzuidgeest]

Er zal wel een markt zijn die de features van jpegXL wel gebruikt. Dat jij en ik het niet weten zegt niet alles.

[Reactie gewijzigd door bzuidgeest op 14 januari 2026 13:24]

[Vipe]

JPEG XL ondersteund onder andere HDR, 32bit color depth, hogere resoluties en progressive decode. Dit zijn allemaal dingen die niet door .webp worden ondersteund.

[Ilmar]

Het heeft vooral nut omdat het buiten de webbrowser wel erg nuttige features heeft die andere formaten niet bieden. Dan hindert het niet ondersteunen door de browser dus behoorlijk, terwijl de browser bouwers het nut niet zo zien.

[kartoenweb]

.webp is volgens mij ook voor website's bedoeld als in minder dataverkeer.
Maar outlook (het programma) ondersteund dan weer geen .webp

[markg85]

We hebben toch ook gif voor animaties dus waarom zouden we video codecs nodig hebben? Of we hebben toch ook bmp voor plaatjes, waarom zou een ander formaat beter zijn?

Ja uiteraard sarcasme. Maar met jouw mening stop je gewoon innovatie. Ik heb geen zin om voor de zoveelste keer jpeg-xl uit te leggen aan de zoveelste halve z... die zelf niet ff kan googlen wat de verschillen ervan zijn.

[Tsjilp]

webp is ook alweer achterhaald, avif schijnt beter qua compressie te zijn en wordt ook door alle moderne browsers ondersteund. https://caniuse.com/avif

[cricque]

Zolang elke browser dit niet ondersteunt ben je er niet veel mee of je moet afhandeling hebben voor elke browser. Dat deed je 20-30 jaar geleden. En heel af en toe misschien nog eens voor specifieke zaken, maar toch niet voor een foto. Uiteraard moet iemand de eerst zijn. Maar als Safari dit niet 100% gaat ondersteunen dan ben je er niet veel mee.

[FiberSam]

Safari ondersteunt het al

[Marcel--]

Niet dat Safari nu zo'n grote gebruikersgroep heeft, maar deze browser ondersteunt dit al.

[deas]

Browsers sturen bij requests een "Accept" header mee, waarin ze aangeven welke formats ondersteund zijn door die browser. Op basis van deze header kan de server bepalen in welk formaat de images worden teruggestuurd.

Dit vereist wel dat de server on-the-fly images kan omzetten, maar daar zijn elegante oplossingen voor. Zie bijvoorbeeld deze image-optimization sample van AWS.

Op deze manier zou je JPEG-XL afbeeldingen kunnen opsturen naar browsers die dat supporten, terwijl je bijvoorbeeld WebP of JPEG naar oudere browsers opstuurt.

[xorpd]

Een van de voordelen van dit formaat ten opzichte van bijvoorbeeld standaard jpegs is dat afbeeldingsbestanden lossless tussen de 20 en 60 procent kleiner zijn.

Moet dat niet lossy zijn? Anders kan er geen vergelijk gemaakt worden met standaard jpeg, toch?

[ArnoutV]

De lossless compressie is verbeterd, dus een betere compressie.
Meer info over bv vergelijking tussen beeldkwaliteit vs grootte
https://jpegxl.info/

[xorpd]

Dat is nieuw voor mij. Ik wist niet dat jpeg ook lossless kon zijn.

[Jazco2nd]

Jpeg niet, jpeg-XL wel.

[Spinal]

Onder meer Safari en Firefox ondersteunen de codec al.

Bij Firefox zit het alleen in Nightly, en achter een feature flag. Niet breed beschikbaar dus. En zowel Safari als Firefox ondersteunen voorlopig geen progressive decoding.

[smiba]

Eindelijk! Ik volg de discussie al jaren op de google issue tracker, ben groot fan van JPEG XL en verwacht dat dit ook veel goeds gaat brengen naar het internet.

Heb zelf al jaren jpeg-xl in gebruik op mijn website, maar alleen Safari had er support voor in de mainstream browser tot nu toe.

[Globefrotter]

Heel goed dat dit wordt ondersteund en dat het daardoor de kans krijgt om meer algemeen gebruikt te geraken, 'mainstream' zogezegd.

Ik gebruik mijn iPad Pro als fotoalbum en zet er al mijn met een Canon R5 gemaakte foto's op.

Ben omgeschakeld van jpg naar jxl. Geweldig! De kwaliteit is echt beter en de bestanden zijn een stuk kleiner, tot wel 40%.

Goede ontwikkeling!

[bewerkers]

Heeft u de de bestanden verliesvrij omgezet?

[Globefrotter]

Nee, 100% instelling onder 'Lossy'. En de 'hoogste comprimering/langzaamst'.

[markg85]

Eindelijk! Dankjewel Adobe (en shopify en apple). Waarom? Adobe heeft jpeg-xl in pdf als standaard gestopt en google wil natuurlijk wel graag pdf kunnen blijven weergeven. Oftewel, daar ligt een grote reden om het "dan maar" te ondersteunen. Maar ook apple heeft het in safari en ook, naar ik meen, shopify stuurt jpeg-xl naar je browser als die dat ondersteund.

Het blijft een smerige streek van google om het er eerst in te zetten en dan met een hoop false onzin redenaties eruit te halen (ze wilde avif pushen, let wel dat het bestaan van dat formaat op dat moment nog in de kinderschoenen stond).

Zonder google zijn machtsmisbruik was jpeg-xl nu gemeengoed in alle browsers.

[Dlsruptor]

Ik heb laatst al mijn foto's omgezet naar Jpeg XL, dus ik ben zeer voor meer ondersteuning voor dit formaat.

[n0elite]

Van lossless naar lossy neem ik aan?

[Dlsruptor]

Nee zelfs van HEIC naar Jpeg XL lossless.

Het ging me er juist om dat ik super scherpe foto’s kon bewaren zonder kwaliteitsverlies maar geen idioot grote bestandsgrootte