JPEG XL: Webformatet, der er bygget til fotografer

JPEG XL (.jxl) er et royaltyfrit billedformat, der giver markant mindre filer end JPEG og samtidig bevarer fine detaljer og bløde toneovergange. I oktober 2026 slog både Chrome og Firefox formatet til som standard, og Safari har vist det siden 2023. Hvis dit website indeholder mange fotos, kan du nu levere billeder i høj kvalitet med mindre filer end i dag. Der er dog stadig et par huller, især i WordPress og i Google billedsøgning.

Nyheden er knap to uger gammel. Chrome 155 kom 6. oktober, og Firefox 158 fulgte seks dage senere. Dermed er formatet gået fra at være en Apple-specialitet til at virke i de browsere, langt de fleste bruger. Denne artikel gennemgår, hvad JPEG XL kan, som andre formater ikke kan, hvordan du tager det i brug, og hvor dette nyere format stadig halter lidt.

Hvad er JPEG XL?

JPEG XL er et billedformat med filendelsen .jxl og MIME-typen image/jxl. Det er standardiseret som ISO/IEC 18181 og udviklet af JPEG-komitéen, altså de samme folk, der stod bag det JPEG-format, nærmest alle har brugt som standard siden 1992.

Formatet kan både komprimere med og uden tab af information. Det understøtter høj bitdybde, brede farverum, HDR, gennemsigtighed og animation, og det kan vise billeder progressivt, så en grov version dukker op, før hele filen er hentet. I et teknisk overblik fra 2025 beskriver udviklerne bag formatet målet som ét format, der kan erstatte JPEG, PNG og GIF.

Mange pointerer, at JPEG XL komprimerer 30-50 % bedre end JPEG. For et billedtungt site er det dog sjældent den mest interessante egenskab, og det vender jeg tilbage til.

Oktober 2026: Chrome og Firefox slår formatet til

JPEG XL har haft en usædvanlig turbulent opvækst. Google fjernede den eksperimentelle understøttelse fra Chrome i 2022 og henviste til lav interesse og til, at WebP og AVIF allerede dækkede behovet. Apple tilføjede formatet i Safari 17 i 2023, og Microsoft gjorde det samme i Windows 11 24H2 i 2025.

I november 2025 skiftede Google kurs. Chrome ville nu tage imod en hurtig og hukommelsessikker dekoder, og løsningen blev jxl-rs, der er skrevet i programmeringssproget Rust. Mozilla havde stillet den samme betingelse, og derfor kunne Chrome og Firefox bruge den samme dekoder.

Kilder: Chrome for Developers, Mozilla/Phoronix, caniuse.com og PiunikaWeb (Edge).

Hvis du slår formatet op lige nu, står der mange steder, at omkring 17 % af alle browsere understøtter JPEG XL. Tallet halter efter virkeligheden, fordi statistikken bygger på data fra før Chrome 155 og Firefox 158 nåede ud. Andelen vil stige kraftigt over de kommende uger, efterhånden som opdateringerne rulles ud. Hvor hurtigt, afhænger blandt andet af, hvornår Microsoft får rettet fejlen i Edge.

JPEG XL, AVIF og WebP: forskellen ligger i billedkvaliteten

AVIF er bedst, når filen skal være så lille som muligt. JPEG XL er bedst, når billedet skal se ud som det, fotografen afleverede.

WebP og AVIF har begge rødder i videoverdenen. WebP bygger på videocodec’et VP8, og AVIF bygger på AV1. Det gør dem ikke dårlige til fotos. AVIF er et stærkt format, der understøtter 10- og 12-bit farver og HDR. Google anbefaler at teste begge formater og placerer JPEG XL’s styrke ved høj kvalitet. AVIF er derfor typisk det oplagte valg, når filen skal være så lille som muligt.

Forskellen viser sig, når kvaliteten skal være høj. Video-codecs er optimeret til levende billeder, hvor hvert enkelt billede kun ses et øjeblik. Et fotografi på en portfolio eller en produktside bliver derimod studeret, ofte i stor størrelse og med zoom. JPEG XL er designet til stillbilleder fra starten og prioriterer at bevare tekstur og fine detaljer.

Det er også Googles egen vurdering. Selvom Google står bag WebP og var med til at udvikle AVIF, anbefaler virksomheden nu at teste begge formater. Ifølge Google er JPEG XL mest nyttigt ved høj billedkvalitet eller tabsfri komprimering, især for fotografier, og når man ønsker finmasket progressiv indlæsning.

Valget mellem formater afhænger derfor af, hvilken slags billeder dit site leverer. Et nyhedssite med hundredvis af små miniaturebilleder har andre behov end en fotograf, en arkitekt eller en webshop med zoombare produktbilleder i stort format.

Fordelene for et billedtungt website

Tekstur og detaljer overlever komprimeringen

Hudtekstur i et portræt, vævningen i et stykke tøj og kornet i et analogt foto er netop de detaljer, aggressive codecs kan have tendens til at glatte ud. Resultatet kan se fint ud i et thumbnail, men voksagtigt ud i fuld størrelse. Med JPEG XL kan du ramme en lavere filstørrelse end JPEG uden at miste den struktur, der får et billede til at virke ægte. For en webshop, hvor kunden zoomer ind på materialet, før hun køber, er det en direkte forretningsmæssig fordel.

Bløde toneovergange uden trappetrin

Enhver, der har fotograferet koncerter, kender problemet. En scene badet i blåt lys og røg bliver til en blød gradient med tusindvis af nuancer. Gemmer du den som 8-bit JPEG eller WebP og komprimerer den til web, falder gradienten fra hinanden i synlige bånd hen over billedet. Fænomenet kaldes banding.

Ifølge specifikationen håndterer JPEG XL alt fra 1-bit stregtegninger til 32-bit HDR med flydende komma. AVIF kan også gemme mere end 8 bit pr. kanal, så her er JPEG XL ikke alene. Forskellen til JPEG og WebP er til gengæld stor, og det gælder himmel, hudtoner og studiebaggrunde lige så meget som scenelys.

Billedet dukker op, før det er hentet

Kan du huske et polaroidbillede, der langsomt fremkaldes i hånden? JPEG XL’s progressive indlæsning fungerer på samme måde. Browseren viser først en grov version af hele billedet og tilføjer derefter detaljer, efterhånden som data ankommer. På et galleri eller en lang produktside føles siden færdig tidligere, især på en dårlig mobilforbindelse.

Der er to forbehold. Den finmaskede progressive indlæsning skal slås til, når du laver filen (se kommandoerne længere nede). Og Safari viser ifølge det tyske fagmedie Dr. Web hverken progressiv indlæsning eller animation, så iPhone-brugere får det færdige billede på én gang.

Dit JPEG-arkiv kan skrumpe uden at du mister en eneste pixel

Det er den fordel, der giver mest for de fleste eksisterende sites. JPEG XL kan pakke en eksisterende JPEG-fil om uden at fjerne billedinformation. Apple angiver besparelsen til omkring 20 % i gennemsnit. En uafhængig test af Chrome 155 fra det japanske udviklerfirma Classmethod fandt det samme niveau: et JPEG i kvalitet 85 gik fra 96.118 til 74.816 bytes, svarende til ca. 22 % mindre.

Det svarer til at vakuumpakke en uldsweater. Det er den samme sweater, når du pakker den ud igen, og den fylder bare mindre i skabet. Ifølge Mozillas dokumentation for webudviklere kan den originale JPEG-fil genskabes bit for bit fra JPEG XL-versionen.

For et site med tusindvis af ældre produktbilleder, nyhedsfotos eller en mangeårig portfolio er det en besparelse helt uden kvalitetstab. Du behøver ikke finde originalerne frem og eksportere igen, og du lægger ikke endnu et lag komprimering oven på det, der allerede er der.

Formatet vinder også frem uden for browseren. DNG 1.7, Adobes åbne råfilformat, kan bruge JPEG XL til at komprimere rå kameradata, og ifølge Apple kan JPEG XL-komprimering få et tabsfrit 48-megapixel ProRAW-billede ned fra 75 MB til 46 MB. Samme format kan altså følge billedet fra kameraet til hjemmesiden.

Googles billedsøgning understøtter ikke JPEG XL endnu

Det her er det spørgsmål, de fleste artikler om JPEG XL springer over, og det er afgørende, hvis du arbejder med SEO.

Googles officielle dokumentation for billed-SEO lister de formater, Google kan indeksere: BMP, GIF, JPEG, PNG, WebP, SVG og AVIF. JPEG XL er ikke på listen. Siden er sidst opdateret i marts 2026, så det kan ændre sig, nu hvor Chrome understøtter formatet. Indtil Google melder andet, skal du dog gå ud fra, at en .jxl-fil ikke bliver vist i Googles billedsøgninger.

Det har tre praktiske konsekvenser:

• Servér aldrig JPEG XL som eneste format. Ifølge Googles dokumentation er det billedet i img-elementets src-attribut, der indekseres, så den skal pege på et format, Google forstår.
• Brug JPEG eller PNG til delingsbilleder (og:image). Det er de formater, sociale platforme og e-mailklienter er sikre på at kunne vise.
• Billeder i struktureret data, fx produktbilleder i Product-schema, bør også pege på et understøttet format.

Den gode nyhed er, at det korrekte fallback-setup nedenfor løser alle tre problemer på én gang.

Sådan bruger du JPEG XL på et billedtungt website

Brug picture-elementet med fallback og flere størrelser

<picture>
  <source type="image/jxl"
    srcset="koncert-800.jxl 800w, koncert-1600.jxl 1600w, koncert-2400.jxl 2400w"
    sizes="(max-width: 900px) 100vw, 900px">
  <source type="image/avif"
    srcset="koncert-800.avif 800w, koncert-1600.avif 1600w, koncert-2400.avif 2400w"
    sizes="(max-width: 900px) 100vw, 900px">
  <img src="koncert-1600.jpg"
    srcset="koncert-800.jpg 800w, koncert-1600.jpg 1600w, koncert-2400.jpg 2400w"
    sizes="(max-width: 900px) 100vw, 900px"
    alt="Sanger i blåt scenelys" width="1600" height="1067" loading="lazy">
</picture>

Browseren vælger det første format, den forstår, og derefter den størrelse, der passer til skærmen. Chrome, Firefox og Safari henter .jxl. Ældre browsere falder tilbage til AVIF og til sidst JPEG, og Google indekserer JPEG-filen i img-elementet. Classmethods test bekræftede, at både .jxl direkte i et img-element og fallback via picture virker i Chrome 155.

Tip: Fjern loading="lazy" på dit hero-billede. Det er typisk sidens LCP-element (Largest Contentful Paint), og det skal hentes med det samme. Læs mere om det i min guide til optimering af billeder til web.

Regnestykket taler for CDN

Kig på eksemplet ovenfor. Tre størrelser i tre formater giver ni filer for ét billede, og et typisk responsivt setup har snarere 4-6 størrelser. Lægger du WebP til som ekstra fallback, ender du med 16-24 filer pr. billede. For et site med 5.000 billeder er det over 100.000 filer, der skal genereres, lagres og holdes opdateret.

Derfor er en CDN den mest realistiske løsning for de fleste billedtunge sites. Du uploader én original, og CDN’et laver formater og størrelser efter behov. Både Classmethods test af Chrome 155 og Mozillas release notes for Firefox 158 bekræfter, at browseren nu sender image/jxl med i sin Accept-header, når den beder om et billede. Et CDN kan derfor se, hvilke browsere der forstår JPEG XL, og levere den rigtige version automatisk. Cloudinary og ImageEngine understøtter allerede formatet.

Konvertér med libjxl

Hvis du vil lave filerne selv, er det officielle værktøj libjxl. Det består af cjxl, der laver JPEG XL-filer, og djxl, der pakker dem ud igen.

# Tabsfri omkodning af eksisterende JPEG
cjxl foto.jpg foto.jxl --lossless_jpeg=1

# Ny eksport fra PNG eller TIFF i visuelt tabsfri kvalitet med progressiv indlæsning
cjxl foto.png foto.jxl -d 1.0 -p

# Gendan det originale JPEG bit for bit
djxl foto.jxl gendannet.jpg

Parameteren -d (distance) styrer kvaliteten. 0 er tabsfri, 1.0 er visuelt tabsfri, og højere tal giver mindre filer. Skalaen måler, hvor meget billedet afviger visuelt fra originalen, og det gør den mere intuitiv end JPEG’s kvalitetsprocenter. -pslår progressiv indlæsning til, og det er ikke standard.

Begrænsninger, du skal kende, før du går i gang

Browserstøtte er kun halvdelen af historien. Resten af værktøjskæden skal også følge med, og her er JPEG XL stadig ungt.

WordPress afviser stadig formatet

For de fleste sites er det den største praktiske forhindring. WordPress’ mediebibliotek afviser fortsat .jxl-filer. Et patch fra core-committer Adam Silverstein har ligget klar siden juni 2026, men det tilhørende ticket, #52788 på WordPress Trac, er stadig lukket.

Historikken giver et fingerpeg om tempoet. WebP blev lanceret af Google i 2010, men kom først i WordPress core med version 5.8 i 2021. AVIF blev standardiseret i 2019 og kom med i WordPress 6.5 i 2024. WordPress venter typisk, til både browsere og serverværktøjer er klar.

Serverværktøjerne er netop en del af problemet. WordPress laver billedstørrelser med PHP-udvidelserne GD eller Imagick. Som WordPress’ egne udviklere noterer i Trac-ticket #62050, understøtter PHP’s GD-udvidelse ikke JPEG XL. Imagick kan, hvis serverens ImageMagick er bygget med libjxl, men det kan du ikke regne med hos et standardhotel. Indtil WordPress følger med, er et billed-CDN eller et plugin, der leverer JPEG XL uden om mediebiblioteket, den farbare vej.

Safari og Edge er kun halvvejs

Safari viser stillbilleder, men ikke animationer og ikke progressiv indlæsning. I Danmark kører 63 % af al mobiltrafik på iOS ifølge StatCounter (september 2026). Det betyder, at en af formatets fotografiske fordele ikke når næsten to ud af tre mobilbrugere endnu.

Edge 155 bygger på samme Chromium-version som Chrome 155, og Microsoft nævner JPEG XL i sine release notes. En test fra PiunikaWeb viste dog, at Edge stadig ikke kunne vise formatet, og en tråd på Reddit beskriver det samme problem. Dit fallback-setup dækker hullet, men regn ikke Edge-brugerne med i dine besparelser endnu.

Redigeringsprogrammerne er ikke modne alle steder

I Adobes community-forum er der flere brugere der melder, at JPEG XL-eksport fra Lightroom og Camera Raw giver uforholdsmæssigt store filer i forhold til JPEG, uanset indstillinger. Test filstørrelserne, før du automatiserer et workflow, og gå ikke ud fra, at et program udnytter formatet optimalt, bare fordi det kan eksportere det.

Tabsfri JPEG XL er tungere at vise

Dr. Web påpeger, at JPEG XL i tabsfri tilstand dekoder markant langsommere end WebP. Til fotos bruger du alligevel tabsgivende komprimering, så det er sjældent et problem. Overvejer du at erstatte PNG-grafik med tabsfri JPEG XL på mobiltunge sider, så mål effekten på dine Core Web Vitals først.

Uden for browseren er formatet stadig fremmed

Windows 11 og macOS kan åbne .jxl-filer, men mange sociale medier, nyhedsbrevssystemer og e-mailklienter er endnu ikke fulgt med. Billeder, der skal deles, mailes eller uploades andre steder, bør derfor stadig eksporteres som JPEG eller PNG, som alle platforme er sikre på at kunne vise.

Min anbefaling

Hvis du har et billedtungt website og kører med CDN, så slå JPEG XL til nu som første valg med AVIF og JPEG som fallback. Start gerne med dit eksisterende arkiv, hvor den tabsfri omkodning giver en sikker besparelse.

Hvis dit site kører på WordPress uden et billed-CDN, så vent på, at WordPress lukker hullet i mediebiblioteket. En hjemmelavet løsning bliver hurtigt noget, du skal vedligeholde i årevis.

Hvis dine billeder primært er små miniaturer og grafik, hvor filstørrelsen betyder mere end detaljerne, er AVIF fortsat et udmærket valg. JPEG XL gør den største forskel der, hvor billedkvaliteten er en del af produktet.

FAQ om JPEG XL