Bildeformater i 2026: når AVIF slår WebP, og når det ikke gjør det

Status for bildeformater i 2026

AVIF har vært "fremtiden" lenge nok til at det nå føles som nåtiden. Nettleserstøtten passerte 95 % global dekning sent i 2024, CDN-er la til automatisk AVIF-transkoding, og de fleste verktøy for bildeoptimalisering leveres nå med AVIF som standard. WebP har på sin side blitt den trygge reserveløsningen — allestedsnærværende, rask å kode og god nok for de fleste bruksområder.

Spørsmålet er ikke lenger om AVIF er bedre i teorien. Det er det. Spørsmålet er om de praktiske avveiningene — kodingstid, modenhet i verktøy, oppførsel i kanttilfeller — gjør det verdt å bytte for akkurat din arbeidsmengde.

Denne artikkelen går gjennom beslutningstreet. Hvis du leverer tusenvis av brukeropplastede bilder, er svaret et annet enn hvis du finjusterer et dusin hero-bilder for markedsføring. Hvis kodingshastighet er viktig for deg, endrer svaret seg igjen.

Der AVIF vinner klart

AVIF bruker AV1-videokodekens intra-frame-komprimering, noe som betyr at det drar nytte av mange års optimalisering for video med bevegelse. Resultatet er konsekvent mindre filstørrelser enn WebP ved tilsvarende opplevd kvalitet, særlig for fotografisk innhold.

I gjentatte tester på tvers av varierte bildesett er AVIF-filer 20–30 % mindre enn WebP ved samme SSIM-score. For høyoppløste bilder — produktbilder, redaksjonelle bilder, alt over 1200px bredt — øker denne forskjellen raskt. En WebP på 2MB blir en AVIF på 1,4MB. Multipliser det med hundre bilder på en side, og båndbreddebesparelsen blir betydelig.

AVIF håndterer også jevne gradienter og områder med lav kontrast bedre enn WebP. WebPs VP8-arv betyr at det kan introdusere banding i himmel, skygger og andre subtile toneoverganger. AVIFs mer sofistikerte transformkoding unngår dette. Hvis bildene dine inneholder mange gradienter — designarbeid, illustrasjoner, solnedganger — vil AVIF se renere ut ved mindre filstørrelser.

Nettleserstøtten er nå sterk nok til at AVIF kan være primærformatet for de fleste nettsteder. Safari la til støtte i 16.4 (mars 2023), som var den siste store etternøleren. Global støtte er over 95 % per tidlig 2026. Det gjenværende gapet er eldre Android-enheter og eldre bedriftsnettlesere, og derfor trenger du fortsatt en reserve.

Der WebP fortsatt gir mening

Kodingshastighet er den største praktiske begrensningen. AVIF-koding er 5–10 ganger tregere enn WebP, avhengig av kvalitetsinnstillinger og enkoderimplementasjon. For brukergenerert innhold — profilbilder, forumvedlegg, alt som lastes opp i sanntid — har denne ventetiden betydning. En WebP-koding som tar 200ms, blir en AVIF-koding på 2 sekunder. Hvis du behandler opplastinger synkront, er det en forsinkelse brukeren merker.

Løsningen er enten å kode asynkront (last opp originalen, vis en plassholder, kod i bakgrunnen) eller å holde seg til WebP for brukergenerert innhold og reservere AVIF for kuraterte ressurser du kontrollerer. Mange nettsteder gjør begge deler: AVIF for markedsføringsbilder, WebP for brukeropplastinger.

WebP har også mer moden verktøystøtte. Alle bildebiblioteker, CMS-utvidelser og CDN-er har støttet WebP i årevis. AVIF-støtten tar igjen forspranget, men kanttilfeller finnes fortsatt. Noen eldre ImageMagick-bygg produserer AVIF-utdata av dårlig kvalitet. Noen CDN-er tar ekstra betalt for AVIF-transkoding. Hvis du arbeider i et begrenset miljø — eldre CMS, begrenset budsjett, stramme tidsfrister — er WebP den enkleste veien.

Til slutt er WebP fortsatt mindre enn JPEG i nesten alle tilfeller, og koding er rask nok for bruk i sanntid. Hvis dagens utgangspunkt er JPEG og du ennå ikke har migrert til moderne formater, er WebP det tryggere første steget. Du kan alltid legge til AVIF senere som en progressiv forbedring.

Det praktiske beslutningstreet

Slik velger du:

• Kuraterte markedsføringsbilder, hero-bilder, redaksjonelle bilder: Bruk AVIF som primærformat, med WebP som første reserve og JPEG som siste reserve. Filstørrelsesbesparelsen rettferdiggjør kodingskostnaden, og du kontrollerer pipelinen.
• Brukergenerert innhold lastet opp i sanntid: Bruk WebP. Kodingshastighet betyr mer enn de siste 20 % i komprimeringseffektivitet, og du har ikke råd til forsinkelser på flere sekunder.
• Illustrasjoner, grafikk med flate farger, skjermbilder: AVIF er bedre enn WebP, men PNG er ofte konkurransedyktig for enkel grafikk med store, flate områder. Test begge. Hvis PNG-filen din allerede er liten og komprimeres godt, er det ikke sikkert formatmigreringen er verdt det.
• Miniatyrbilder og små bilder: WebP er som regel helt greit. Den absolutte bytebesparelsen fra AVIF er liten (en WebP på 10KB blir en AVIF på 8KB), og kodingshastighet betyr mer i stor skala.
• Støtte for eldre nettlesere er kritisk: Hold deg til WebP som primært moderne format. AVIFs dekning på 95 % er utmerket, men hvis du betjener en brukerbase med eldre enheter eller bedriftsmiljøer, er WebPs nesten universelle støtte tryggere.

Hvis du er usikker, er det tryggeste mønsteret å levere AVIF til nettlesere som støtter det, med WebP som reserve og JPEG som siste reserve. <picture>-elementet gjør dette enkelt:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description">
</picture>

Denne tilnærmingen gir deg det beste fra begge verdener: maksimal komprimering for moderne nettlesere, trygge reserver for eldre.

Kodingsinnstillinger som betyr noe

Hvis du tar i bruk AVIF, har kodingsinnstillingene større påvirkning på utdatakvaliteten enn de har med WebP. AVIFs fleksibilitet betyr at det finnes flere måter å få et dårlig resultat på.

De to innstillingene som betyr mest, er quality og speed. Quality er enkelt: høyere tall betyr bilder som ser bedre ut, og større filer. For AVIF er en quality-innstilling på 75–85 vanligvis det beste kompromisset for fotografisk innhold. Under 70 begynner du å se merkbare artefakter. Over 90 vokser filstørrelsene kraftig uten meningsfulle kvalitetsgevinster.

Speed styrer hvor mye tid enkoderen bruker på å optimalisere resultatet. Tregere koding gir mindre filer, men gevinsten avtar raskt. De fleste enkodere bruker en skala fra 0–10, der 0 er tregest og 10 er raskest. En speed-innstilling på 6–8 er et godt kompromiss: kodingen er rask nok for satsvis behandling, og filstørrelsene ligger innenfor 10–15 % av det teoretiske minimumet.

Hvis du koder AVIF på serveren, bør du bruke en nyere versjon av libavif eller avifenc. Eldre enkodere (før 2024) produserer merkbart dårligere utdata ved samme filstørrelse. Formatet modnes fortsatt, og forbedringene i enkodere har vært betydelige.

Hva med JPEG XL?

JPEG XL er teknisk overlegent både AVIF og WebP. Det komprimerer bedre, koder raskere, støtter tapsfri komprimering og håndterer et bredere spekter av bildetyper. Det er også et dødt format.

Google fjernet JPEG XL-støtte fra Chrome i 2022, med lav bruk og kompleksitet som begrunnelse. Apple la aldri til støtte. Per 2026 støttes JPEG XL bare i Firefox og Safari Technology Preview, noe som betyr at det ikke er egnet for produksjonsbruk. Med mindre nettleserleverandørene snur — noe som er lite sannsynlig — vil JPEG XL forbli et format for entusiaster og arkiveringsarbeidsflyter, ikke for weben.

Migreringsveien

Hvis du går fra JPEG til moderne formater, er den tryggeste veien:

1. Kartlegg dagens bildepipeline. Identifiser hvor bildene kommer fra (CMS, brukeropplastinger, CDN), hvordan de behandles, og hvilke formater du leverer i dag. Hvorfor bildebehandling i nettleseren er en personverngevinst dekker noen av avveiningene rundt hvor bildebehandling skjer.
2. Start med WebP. Det er raskt å kode, har bred støtte og gir umiddelbare reduksjoner i filstørrelse. Dette er første steg med lav risiko.
3. Legg til AVIF for kuratert innhold. Når WebP fungerer pålitelig, legg til AVIF for bilder med høy verdi der filstørrelsen betyr mest. Test kodingstider og sørg for at CDN-et eller bildetjenesten din støtter det.
4. Følg med på nettleserstøtten. AVIF-dekningen er utmerket nå, men hvis analysene dine viser en betydelig prosentandel brukere på eldre nettlesere, bør du beholde WebP som primærformat.
5. Mål effekten. Bruk overvåking av reelle brukere til å følge med på sidelastetider og Largest Contentful Paint før og etter migreringen. Slik leser du en Lighthouse-rapport uten å få panikk er en nyttig guide til å tolke ytelsesmålinger.

Målet er ikke å bruke det nyeste formatet fordi det er nytt. Målet er å levere mindre bilder uten å ofre kvalitet, noe som forbedrer sidehastigheten og reduserer båndbreddekostnader. AVIF gjør dette bedre enn WebP i de fleste tilfeller, men de praktiske begrensningene — kodingshastighet, verktøy, nettleserstøtte — betyr at WebP fortsatt er riktig valg for noen arbeidsmengder.

Viktige punkter

• AVIF er 20–30 % mindre enn WebP ved tilsvarende kvalitet, særlig for fotografisk innhold og bilder med gradienter.
• Koding av AVIF er 5–10 ganger tregere enn WebP, noe som gjør det upraktisk for brukeropplastinger i sanntid med mindre du koder asynkront.
• Nettleserstøtten for AVIF er over 95 % globalt, men WebPs nesten universelle støtte gjør det til den tryggere reserven.
• For kuraterte markedsføringsbilder bør du bruke AVIF som primærformat med WebP- og JPEG-reserver. For brukergenerert innhold bør du holde deg til WebP.
• JPEG XL er teknisk overlegent, men har ingen levedyktig nettleserstøtte og bør ikke brukes for produksjonsnettsteder.

FAQ

Q: Kan jeg levere AVIF uten en reserve?

A: Ikke ennå. AVIF-støtten er over 95 %, men det etterlater fortsatt millioner av brukere på eldre nettlesere. Inkluder alltid en WebP- eller JPEG-reserve ved å bruke <picture>-elementet. Nettleseren velger automatisk det beste formatet den støtter.

Q: Støtter AVIF transparens?

A: Ja. AVIF støtter en alfakanal, noe som gjør det til en levedyktig erstatning for PNG i tilfeller der du trenger transparens. Filstørrelsene er som regel mindre enn PNG, selv om koding er tregere.

Q: Bør jeg kode alle eksisterende bilder på nytt til AVIF?

A: Bare hvis båndbreddebesparelsen rettferdiggjør innsatsen. Start med sider med høy trafikk og store bilder der effekten er mest synlig. For sider med lav trafikk eller små bilder er avkastningen minimal. Fokuser på nytt innhold først, og fyll deretter på selektivt.

Q: Hva er det beste verktøyet for satsvis AVIF-koding?

A: avifenc (del av libavif) er det mest brukte kommandolinjeverktøyet. For GUI-verktøy støtter både Squoosh (nettbasert) og ImageOptim (Mac) AVIF. De fleste moderne CDN-er og bildetjenester (Cloudflare, Cloudinary, imgix) kan transkode til AVIF automatisk.

Q: Fungerer AVIF med responsive bilder og srcset?

A: Ja. Bruk <picture>-elementet med flere <source>-elementer for formatreserver, og srcset innenfor hvert <source> for responsiv størrelsestilpasning. Nettleseren velger det beste formatet og den beste størrelsen basert på støtte og viewport-bredde.

<!-- tool-cta:start -->

💡 Prøv dette: Sammenlign de to formatene på dine egne ressurser med Image Converter, som kan eksportere både AVIF og WebP, slik at du kan måle størrelse og kvalitet i praksis.

<!-- tool-cta:end -->

Kilder

• AVIF vs WebP: A Comprehensive Comparison — Detaljert analyse av komprimeringseffektivitet og kvalitetsinnstillinger på tvers av ulike bildetyper.
• Can I use AVIF? — Oppdaterte data om nettleserstøtte for AVIF-bildeformatet.
• libavif GitHub repository — Referanseimplementasjon av enkoder og dokumentasjon for AVIF.
• Web Almanac: Images — Årlig rapport om bruk av bildeformater og ytelse på tvers av weben.