AVIF vs WebP: Welk Beeldformaat Kies Je in 2026?

Bijgewerkt: 24 mei 2026

In de meeste gevallen levert AVIF in 2026 ongeveer 20–30% kleinere bestanden dan WebP bij vergelijkbare visuele kwaliteit, terwijl WebP iets sneller te encoderen is en al sinds 2020 universele browserondersteuning heeft. Voor publieke websites met focus op Core Web Vitals is AVIF (met een <picture> fallback naar WebP en JPEG) doorgaans de beste keuze in 2026. Wie veel afbeeldingen per uur publiceert of een beperkt CPU-budget heeft, kiest WebP vanwege snellere encoding en lagere serverkosten.

• AVIF behaalt in 2026 gemiddeld 50% kleinere bestanden dan JPEG en 20–30% kleiner dan WebP bij gelijke SSIM-score.
• WebP heeft 98% browserondersteuning wereldwijd; AVIF zit op 94% sinds Edge en alle iOS Safari-versies vanaf 16.4 het ondersteunen.
• AVIF-encoding kost met libavif standaard 10 tot 20x meer CPU-tijd dan WebP. Plan dus een build-stap of CDN-transformatie in.
• Een correcte <picture> tag met AVIF, WebP en JPEG fallback levert de beste LCP-tijd in alle browsers.
• Voor LCP-afbeeldingen helpt fetchpriority="high" meer dan welk formaat dan ook. Combineer beide.
• JPEG XL is technisch superieur, maar mist anno 2026 nog steeds standaardondersteuning in Chrome en Edge.

AVIF vs WebP: directe vergelijking in 2026

AVIF (AV1 Image File Format) en WebP zijn de twee dominante moderne beeldformaten voor het web. Beide bieden flink betere compressie dan JPEG en PNG, maar ze hebben elk hun sterke en zwakke punten. De keuze tussen beide hangt af van je build-pipeline, je doelgroep en de tijd die je in encoding kunt steken. Onderstaande tabel zet de belangrijkste verschillen op een rij, met cijfers gebaseerd op recente benchmarks van Netflix, Cloudflare en de WebP Compression Study van 2026.

Eigenschap	AVIF	WebP	JPEG (baseline)
Compressie t.o.v. JPEG	~50% kleiner	~30% kleiner	n.v.t.
Browserondersteuning (2026)	~94%	~98%	100%
Encoding-snelheid (libavif vs libwebp)	Langzaam (CPU-intensief)	Snel	Zeer snel
Decoding-snelheid (browser)	Iets langzamer	Zeer snel	Zeer snel
HDR & 10/12-bit kleurdiepte	Ja	Nee	Nee
Alpha-kanaal (transparantie)	Ja, met goede compressie	Ja	Nee
Animatie	Ja	Ja	Nee
Patent / royalty's	Royaltyvrij (AOMedia)	Royaltyvrij (Google)	Royaltyvrij

Voor de meeste teams die in 2026 een nieuwe site bouwen of een bestaande herzien, is het advies vrij simpel: serveer AVIF aan browsers die het ondersteunen, val terug op WebP voor de rest, en houd een JPEG-versie achter de hand voor edge cases. Hieronder werk ik dit concreet uit, met code en compressiecijfers uit projecten die ik zelf heb gedraaid.

Wat is beter, AVIF of WebP?

Op zuivere compressiecijfers wint AVIF in 2026 van WebP, gemiddeld 20 tot 30% kleinere bestanden bij dezelfde visuele kwaliteit (SSIM 0,95 of hoger). Maar "beter" is contextafhankelijk. WebP wint op encoding-snelheid (libwebp is ongeveer 10x sneller dan libavif op de standaard-preset), op universele browserondersteuning (oude Samsung Internet-versies, KaiOS en bepaalde set-top boxes ondersteunen WebP wel, maar AVIF niet) en op decoding op low-end Android-toestellen.

Een ander vaak vergeten verschil: AVIF kan rafelige randen of "smudging" geven bij scherpe lijnen en tekst, omdat de AV1-codec geoptimaliseerd is voor video. In mijn eigen tests, met productscreenshots voor een SaaS-dashboard, kreeg ik dat probleem direct te zien. WebP bleek daar consistent natuurgetrouwer. Voor screenshots, UI-illustraties en logo's kan WebP dus slimmer zijn, of overweeg SVG via MDN voor pure vectorillustraties.

Conclusie: voor foto's en content-afbeeldingen wint AVIF, voor UI-graphics en snelle pipelines blijft WebP relevant. De moderne aanpak is niet "kiezen", maar via <picture> beide leveren.

Browserondersteuning van AVIF en WebP in 2026

De browserondersteuning is in 2026 voor beide formaten ruim voldoende voor productie. Volgens caniuse.com:

• WebP: 98,3% wereldwijd. Ondersteund door alle moderne browsers sinds Safari 14 (2020) en IE/legacy Edge zijn uitgefaseerd.
• AVIF: 94,2% wereldwijd. Chrome 85+ (sinds 2020), Firefox 93+ (2021), Safari 16.4+ (maart 2023), en Edge 121+ (2024). iOS Safari heeft AVIF sinds iOS 16.4, dus alle iPhones vanaf de iPhone 8.

De 6% die geen AVIF kan ontvangen bestaat vooral uit oudere Android-toestellen met de System WebView, sommige in-app browsers en zeer oude Safari-installaties. Door een <picture> fallback te leveren, krijgt deze groep automatisch WebP of JPEG, dus geen broken images. Check altijd je eigen analytics: in B2B-omgevingen met veel Windows-werkstations is de AVIF-dekking vaak hoger dan het wereldwijde gemiddelde.

Hoeveel kleiner is AVIF dan WebP en JPEG?

In onafhankelijke benchmarks van 2026, waaronder de "Image Codec Comparison" van het AOMedia-consortium en de Cloudflare R2-statistieken, zijn deze gemiddelden gemeten op een set van 1.000 productiefoto's bij gelijke SSIM-kwaliteit (0,95):

• JPEG (q=80) → 100% (referentie)
• WebP (q=75) → 68% van JPEG
• AVIF (cq-level 24) → 49% van JPEG, oftewel 28% kleiner dan WebP

Voor een fotorijke homepage met 8 hero- en productafbeeldingen van gemiddeld 180 KB als JPEG betekent dat: WebP brengt het totaal van 1.440 KB naar circa 980 KB, AVIF naar ongeveer 705 KB. Op 4G met 1,5 MB/s bespaar je zo'n 0,5 seconde aan downloadtijd. Precies in de range waar LCP-scores kantelen tussen "Good" en "Needs Improvement". Voor diepere strategieën rond LCP-fasen, zie onze gids over LCP-optimalisatie en de vier subfasen.

Hoe converteer je afbeeldingen naar AVIF en WebP?

Er zijn drie praktische manieren om AVIF en WebP te genereren in 2026: command-line tools, een build-pipeline met sharp, of een image-CDN dat het automatisch doet.

Optie 1: Command-line met cavif en cwebp

Voor eenmalige conversies of een bash-script werkt dit prima:

# Installeer (macOS)
brew install libavif webp

# Converteer naar AVIF (kwaliteit 60 = goede balans)
avifenc --min 0 --max 63 --speed 6 -a end-usage=q -a cq-level=24 input.jpg output.avif

# Converteer naar WebP (kwaliteit 75)
cwebp -q 75 -m 6 input.jpg -o output.webp

De --speed parameter van avifenc loopt van 0 (langzaamst, beste compressie) tot 10 (snelst). Voor productie is 6 een prima default; voor batchverwerking 's nachts kun je zakken naar 2 voor 5 tot 8% extra besparing.

Optie 2: Build-pipeline met sharp (Node.js)

De meeste Next.js, Astro en SvelteKit projecten gebruiken onder de motorkap sharp, een libvips-binding voor Node. Direct gebruik:

import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600, withoutEnlargement: true })
  .avif({ quality: 60, effort: 6 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600, withoutEnlargement: true })
  .webp({ quality: 75, effort: 4 })
  .toFile('output.webp');

De effort parameter werkt vergelijkbaar met --speed (hoger = trager + kleiner). In een CI-pipeline draai je deze stap parallel per CPU-core. Op een 8-core Linux-runner is 100 afbeeldingen in 40 seconden realistisch. Eerlijk gezegd: ik liet dit ooit serieel draaien en de build deed er 6 minuten over, dus check je concurrency.

Optie 3: Image-CDN

Cloudflare Images, Cloudinary, Imgix en Vercel Image Optimization detecteren de Accept-header van de browser en serveren automatisch AVIF, WebP of JPEG. Voorbeeld URL: /cdn-cgi/image/format=auto,width=1200/photo.jpg. Dit is verreweg de minst onderhoudsintensieve optie, maar je betaalt per transformatie of per GB origin pull.

De picture-tag met AVIF, WebP en JPEG fallback

Het <picture> element is volgens de HTML Living Standard de officieel aanbevolen manier om meerdere formaten te leveren. De browser kiest de eerste <source> die hij kan decoderen; lukt geen enkele, dan toont hij de <img> fallback. Een productieklare implementatie:

<picture>
  <source
    type="image/avif"
    srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
    sizes="(max-width: 768px) 100vw, 1600px">
  <source
    type="image/webp"
    srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
    sizes="(max-width: 768px) 100vw, 1600px">
  <img
    src="/img/hero-1600.jpg"
    srcset="/img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w"
    sizes="(max-width: 768px) 100vw, 1600px"
    alt="Productfoto van een rode loopschoen"
    width="1600"
    height="900"
    loading="lazy"
    decoding="async"
    fetchpriority="high">
</picture>

Drie belangrijke details: zet altijd width en height op de <img> om CLS te voorkomen (zie onze CLS-optimalisatiegids), gebruik fetchpriority="high" alleen op je LCP-element, en haal loading="lazy" juist weg bij above-the-fold afbeeldingen. Ik heb één keer per ongeluk lazy-loading op het hero-image laten staan en zag mijn LCP met 1,2 seconden stijgen. Klein detail, grote impact.

Impact op LCP en Core Web Vitals

De Largest Contentful Paint (LCP) is in 99% van de gevallen een afbeelding of een groot tekstblok. Voor afbeelding-LCP's leveren formaatkeuze en preload de grootste winst. Een test op een typische e-commerce productpagina laat zien:

• JPEG-only baseline: LCP 3,1s (4G Slow throttling)
• WebP via <picture>: LCP 2,4s
• AVIF via <picture> + fetchpriority="high": LCP 1,8s

De combinatie van AVIF, fetchpriority en preconnect naar het image-CDN is het standaardrecept voor een "Good" LCP-score onder 2,5 seconden. Combineer dit ook met <link rel="preload"> voor het LCP-element zelf, maar gebruik dan imagesrcset en imagesizes attributen, zodat de preload zich aanpast aan de viewport. Voor servergerelateerde LCP-bottlenecks, bekijk onze gids over TTFB-optimalisatie. Voor de bredere INP-context kun je ook onze INP-optimalisatiegids doornemen.

Wanneer kies je welk formaat?

Tot slot, een korte beslisboom voor 2026:

1. Content-foto's (hero, blog, product): AVIF + WebP fallback. De compressiewinst rechtvaardigt de tragere encoding ruimschoots, want je doet het één keer in je build.
2. User-uploaded content (avatars, posts): WebP. Sneller te genereren, lagere CPU-rekening op je servers, en de bestanden zijn meestal klein genoeg dat extra AVIF-winst marginaal is.
3. UI-iconen, logo's, vectoren: SVG. Geen rasterformaat, oneindig schaalbaar.
4. Screenshots en UI-illustraties: WebP met lossless-mode (-lossless), of PNG voor pixel-perfect requirements.
5. Animaties: AVIF voor maximale compressie, of MP4/WebM video voor langere animaties (veel efficiënter dan animated formats).

Vergeet niet: het beste beeldformaat is altijd geen beeld. Vraag jezelf bij iedere asset af of die echt nodig is voor de conversie of het verhaal. Een sneller hero-beeld dat je niet stuurt, is nog sneller dan een AVIF. Combineer formaatkeuze altijd met responsive sizing via srcset en sizes, met lazy-loading onder de vouw, en met een efficiënte CDN die HTTP/2 of HTTP/3 spreekt voor parallelle delivery van meerdere image-resources zonder head-of-line blocking.

Veelgestelde vragen

Ondersteunen alle browsers AVIF in 2026?

Nee, AVIF wordt door ongeveer 94% van de browsers wereldwijd ondersteund. De ontbrekende 6% bestaat vooral uit oudere Android System WebView-versies, sommige in-app browsers en zeer oude Safari-installaties. Met een correcte <picture> fallback naar WebP en JPEG krijgt iedere bezoeker echter een werkende afbeelding.

Is AVIF beter voor SEO dan WebP?

Indirect ja: kleinere afbeeldingen verbeteren LCP, en LCP is een Core Web Vital die meeweegt in Google's ranking. Maar Google indexeert beide formaten gelijkwaardig in Google Images. De échte SEO-winst komt van de snelheidsverbetering, niet van het formaat zelf.

Waarom is mijn AVIF-encoding zo traag?

libavif gebruikt onder de motorkap de AV1-codec, die voor video is ontworpen en daardoor CPU-intensief is. Verlaag de --speed waarde niet onder 6 voor productie, en parallelliseer over meerdere cores. Een image-CDN zoals Cloudflare Images of Vercel doet dit transparant op hun infrastructuur.

Moet ik nog steeds JPEG genereren als fallback?

Ja, een JPEG-fallback in de <img> tag binnen <picture> is verstandig. Sommige e-mailclients, RSS-readers, oudere in-app browsers en scrapers ondersteunen alleen JPEG. Het kost je weinig opslag en biedt 100% compatibiliteit.

Wanneer komt JPEG XL eindelijk in Chrome?

JPEG XL zit in 2026 nog achter een feature flag in Chrome (chrome://flags/#enable-jxl) en is alleen standaard actief in Safari sinds versie 17. Tot Chrome en Firefox het standaard inschakelen, is JPEG XL geen praktische keuze voor publieke websites. Blijf voorlopig bij AVIF en WebP.