WebP vs AVIF vs JPEG: welk beeldformaat kies je in 2026?

Korte samenvatting: AVIF is 20–30% kleiner dan WebP en 30–50% kleiner dan JPEG. WebP is grofweg 25–35% kleiner dan JPEG. AVIF codeert 5–20× trager dan WebP, terwijl WebP van de drie het snelst decodeert. De aanbevolen workflow voor 2026: serveer eerst AVIF, val terug op WebP, houd JPEG als universeel vangnet en laat de browser kiezen via het <picture>-element.

Voor de meeste lezers is dat genoeg. De interessante vraag is wanneer je AVIF júist niet moet inzetten. Sla het over bij krappe CI-budgetten waar coderingstijd belangrijker is dan bytes. Houd het achter de hand bij realtime gebruikersuploads, want AVIF-codering aan de browserkant is nog wisselvallig. Houd JPEG als primair formaat als je iOS 16.0–16.3 of oudere Edge in het wild moet ondersteunen. Overal anders wint AVIF op bestandsgrootte, mits je <picture>-markup klopt en je CDN het juiste MIME-type verstuurt.

De rest van deze gids gaat over het werkende detail: ondersteuningscijfers voor 2026, een benchmark op een echte foto, een beslissingsboom per use case, bruikbare <picture>-patronen, conversiecommando’s en de vier valkuilen die teams tijd kosten. Wil je alleen de conversie geregeld hebben, dan doet onze gratis afbeelding comprimeren tool JPEG, PNG, WebP en AVIF in de browser zonder iets te uploaden.

1. Browserondersteuning in 2026: WebP op 97%, AVIF op 93%

Sinds Edge AVIF uitleverde is de ondersteuningskloof versmald tot een paar procent van het wereldwijde verkeer. De vraag is niet meer “wordt het ondersteund” maar “wat serveren we aan de laatste 3%?“

1.1 WebP: de veilige standaard

WebP verscheen in 2012 in Chrome, in Firefox 65 (2019), Edge 18 (2018) en Safari 14 (2020). In mei 2026 zet caniuse de wereldwijde ondersteuning op grofweg 97%. WebP is inmiddels een veilige fallback, niet meer een experimenteel alternatief. Als je één niet-JPEG-formaat serveert, dan WebP.

1.2 AVIF: nu bruikbaar als primair formaat

AVIF kwam in Chrome 85 (augustus 2020) en Firefox 93 (oktober 2021). Safari 16.4 zette het in maart 2023 aan op macOS en iOS. Edge was de hekkensluiter en voegde decode-ondersteuning pas toe in 121 (januari 2024). Wereldwijde dekking in mei 2026 is ongeveer 93–95%.

Eén belangrijk detail: iOS 16.0–16.3 heeft een bekende AVIF-decode-bug die Safari op bepaalde afbeeldingen kan laten crashen. Die builds leven nog op apparaten die door MDM in zakelijke omgevingen zijn vastgezet, dus AVIF zonder werkende WebP- of JPEG-fallback is een reëel risico op een storing. Zet AVIF dus altijd als primair formaat in samen met een fallback, en niet zonder.

1.3 Korte compatibiliteitsmatrix

Formaat	Wereldwijde ondersteuning (mei 2026)	Belangrijkste beperking
JPEG	100%	Grootste bestanden; geen transparantie; geen HDR
WebP	~97%	Geen HDR of 10-bits kleur
AVIF	~93–95%	Trage codering; iOS 16.0–16.3 decode-bug; vereist Edge 121+

2. Kernverschillen: compressie, snelheid, functies

2.1 Compressie-efficiëntie op een echte foto

Eén benchmark vanuit dezelfde bron. Een landschapsfoto van 4000×3000, originele PNG van zo’n 24 MB, opnieuw gecodeerd op een visueel vergelijkbare kwaliteit:

Codering	Grootte	Vs JPEG-baseline
JPEG q75 (mozjpeg)	~2,1 MB	0% (baseline)
WebP q75 (libwebp)	~1,4 MB	33% kleiner
AVIF q60 (libavif, cpu-used 4)	~1,0 MB	52% kleiner

AVIF q60 is hier visueel gelijkwaardig aan JPEG q80 en WebP q75. Kwaliteitsschalen zijn niet uitwisselbaar tussen codecs. “JPEG q75 hercoderen naar AVIF q75” is een veelgemaakte beginnersfout: je houdt een veel te grote AVIF over die er identiek uitziet aan de bron.

2.2 Coderingssnelheid: de 5–20×-belasting

AVIF comprimeert harder omdat het meer werk verzet. Met libavif op de standaardinstelling cpu-used 4 doet een afbeelding van 4000×3000 er 5–20× langer over dan met libwebp en grofweg 50× langer dan met mozjpeg. Die kosten stapelen zich op in CI-builds, Lambda cold starts en pipelines die duizenden assets opnieuw coderen.

Er zijn twee manieren om dit te beperken. cavif --speed 9 (of libavif cpu-used 9) komt binnen 3× van libwebp tegen 5–8% grotere bestanden. En cache agressief: een content-addressed asset-pipeline die ongewijzigde bronnen overslaat, verandert een trage codec in eenmalige kosten.

2.3 Kleurdiepte en HDR

JPEG en WebP houden op bij 8-bits sRGB. AVIF verwerkt 10- en 12-bits kleur, Rec. 2020, DCI-P3 en PQ/HLG-overdrachtsfuncties native. Voor HDR-videothumbnails, professionele fotogalerijen of drukproeven in de browser is AVIF vandaag de enige gestandaardiseerde optie.

2.4 Transparantie en animatie

JPEG kan geen van beide. WebP en AVIF ondersteunen allebei alpha en animatie. Voor het vervangen van transparante PNG codeert AVIF alpha compacter: een UI-illustratie die als WebP 30–40% krimpt, krimpt als AVIF vaak 50–70%.

3. Beslissingsboom: welk formaat voor welke klus

3.1 Statische sites: blogs, marketingpagina’s, documentatie

AVIF primair, WebP als fallback, JPEG als vangnet. Codering gebeurt eenmalig in CI, dus de 5–20×-belasting wordt in buildtijd betaald, niet in gebruikerstijd. Dit is het standaardscenario voor het drie-source <picture>-patroon uit sectie 4.

3.2 Gebruikersuploads: avatars, UGC, formulierbijlagen

Comprimeer in de browser naar WebP en hercodeer asynchroon op de server naar AVIF. Aan de browserkant werkt canvas.toBlob('image/avif') vandaag alleen op Chrome 99+, dus AVIF kan niet het uploadpad zijn. WebP comprimeert snel in de browser en bespaart bandbreedte op de upload zelf.

Voor een diepere vergelijking van client-side bibliotheken (Squoosh, browser-image-compression, Compressor.js) en hoe die samenwerken met server-side Sharp of Imagemin, zie de zustergids gids afbeeldingcompressie: browser vs Node.js. Formaatkeuze en verwerkingslocatie staan los van elkaar; deze gids behandelt de formaat-as.

3.3 HDR en hoogwaardige fotografie

Alleen AVIF. Niets anders op de open webstack ondersteunt vandaag 10- of 12-bits kleur. Sla de fallback over voor HDR-only assets, of accepteer dat de JPEG-fallback SDR is.

3.4 Doelgroepen met veel oude browsers

JPEG primair, WebP optioneel, geen AVIF. Overheidsportalen, bepaalde Oost-Aziatische zakelijke omgevingen en B2B-tools met lange apparaatstaarten laten in analytics soms 5–10% IE/oude-Edge-verkeer zien. WebP is nu veilig; AVIF nog niet.

3.5 Realtime CDN-aflevering

Server-side libvips of Sharp die WebP streamt, met AVIF gegenereerd door een achtergrondworker en uitgeleverd bij cache-hit. Blokkeer het antwoord niet op AVIF-codering. Cloudflare Polish, Vercel Image Optimization en Cloudinary f_auto automatiseren dit patroon.

4. De `<picture>`-fallback, goed gedaan

Het <picture>-element bestaat juist zodat de browser de best ondersteunde bron kan kiezen. Drie lagen, met AVIF bovenaan, geven je het optimale bytebudget zonder dat het op oudere clients breekt.

4.1 De drielagige basis

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Berglandschap bij zonsondergang"
       loading="lazy" decoding="async" />
</picture>

Een paar opmerkingen hierbij. De browser loopt de <source>-elementen van boven naar beneden af en kiest de eerste waarvan hij type kent; de rest wordt genegeerd, niet gedownload. De <img>-tag is het daadwerkelijk gerenderde element en erft attributen (alt, sizes, classes) ongeacht welke source wint. En width/height op de <img> zijn in 2026 niet optioneel: ze reserveren ruimte en voorkomen Cumulative Layout Shift.

Voor afbeeldingen boven de vouw vervang je loading="lazy" door loading="eager" fetchpriority="high". Lazy-loading van de LCP-afbeelding is een van de meest voorkomende valkuilen voor Core Web Vitals.

4.2 Responsief plus formaat: het volledige patroon

Heb je ook responsieve resoluties nodig, herhaal dan srcset binnen elke <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Berglandschap bij zonsondergang"
       loading="lazy" decoding="async" />
</picture>

Klopt, dat zijn negen gegenereerde bestanden per afbeelding. Op deze schaal kun je niet zonder een buildstap; sectie 5.3 behandelt wat je daarvoor kunt inschakelen.

4.3 Server-side `Accept`-onderhandeling als alternatief

Als je CDN het ondersteunt, krimpt content negotiation de markup tot één <img>-tag. De browser stuurt Accept: image/avif,image/webp,image/apng,*/* en het CDN antwoordt op dezelfde URL met het best ondersteunde formaat.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto en CloudFront met Lambda@Edge implementeren dit allemaal. De afweging: kleinere HTML en één URL per afbeelding, maar CDN-lock-in en lastiger lokaal debuggen. Een gangbare verdeling is CDN-onderhandeling voor marketingpagina’s en expliciete <picture> voor product-UI waar deterministisch gedrag belangrijk is.

5. Hoe converteer je afbeeldingen tussen formaten

5.1 In de browser, zonder upload

Voor een eenmalige klus of kleine batch is browser-only het snelste pad. Sleep een JPEG in de gratis afbeelding comprimeren tool, kies WebP of AVIF als uitvoer en het bestand verlaat je machine niet. AVIF als invoer wordt overal ondersteund. AVIF als uitvoer gebruikt native browsercodering op Chrome 85+ en valt op browsers die nog geen AVIF kunnen coderen transparant terug op WebP.

5.2 Commandoregel voor build-pipelines

Voor een productiepipeline wil je deterministische output en reproduceerbare builds. Deze drie commando’s zijn echt:

# AVIF: cavif (Rust, eenvoudig te installeren via cargo of brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (officiële Google libwebp)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Beide, plus resize, via libvips (snelste voor batches)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed loopt van 0 (langzaamst, kleinst) tot 10 (snelst, grootst). De standaard 4 is een prima keuze voor nightly builds; zet hem op 9 voor PR-previews waar snelheid belangrijker is dan bytes.

5.3 Integratie in de build-pipeline

De meeste static-siteframeworks omhullen deze encoders al. Pak degene die bij je stack past:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programmatisch — Sharp (Node.js)
import sharp from 'sharp';

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

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

Voor piepkleine assets (iconen onder ongeveer 5 KB, inline-avatars, e-mailheaders) sla je het netwerk volledig over en plaats je ze inline als data-URI met Base64-codering. Dat ruilt een HTTP-verzoek voor een paar extra bytes HTML; meestal winst onder ~5 KB.

Twijfel je tussen client-side en Node-side compressiebibliotheken (Sharp vs Squoosh vs browser-image-compression), dan gaat de gids afbeeldingcompressie: browser vs Node.js dieper in op benchmarks en afwegingen.

6. Valkuilen en misvattingen

6.1 “AVIF wint altijd”: niet bij screenshots en line art

AVIF blinkt uit op continuous-tone-foto’s. Op screenshots met scherpe tekst, UI-opnames en pixel art produceert WebP vaak kleinere bestanden bij gelijkwaardige kwaliteit. De deblocking van AVIF kan subtiele banding introduceren in vlakke kleurvelden. Doe conversies beide kanten op en kies de winnaar per assetklasse.

6.2 “Lossless WebP vervangt transparante PNG perfect”: bijna, niet identiek

Lossless WebP is wezenlijk kleiner dan PNG, doorgaans zo’n 26%. Let wel op: “lossless” geldt voor de gecomprimeerde afbeelding, maar de encoder kan in regio’s met sterke gradiënten alpha-afronding nog steeds wijzigen. Voor pixelnauwkeurige reproductie (medische beelden, archiefassets, alles wat juridisch identiek moet zijn aan de bron) houd je PNG. Voor al het overige is lossless WebP netto winst.

6.3 “Upload gewoon .avif-bestanden”: je CDN weet misschien niet wat dat is

Oudere nginx- en Apache-configs dateren van vóór AVIF. Als /etc/nginx/mime.types image/avif avif; niet kent, serveert nginx AVIF als application/octet-stream. De browser ziet het verkeerde Content-Type, weigert de afbeelding te renderen en valt stilletjes terug op JPEG, waarmee de hele optimalisatie ontkracht is. Doe na een deploy een curl op je asset-URL en controleer de Content-Type-header. Een paar seconden controle bespaart later veel debugtijd als AVIF in productie niet werkt.

6.4 De AVIF-crash op iOS 16.0–16.3

Sommige AVIF-bestanden veroorzaken een Safari-decodecrash op iOS 16.0–16.3. De bug is opgelost in 16.4 (maart 2023), maar zakelijke MDM en trage OEM-updates houden oudere apparaten in leven. Mitigatie: lever nooit AVIF zonder een werkende WebP-source in dezelfde <picture>, en zet AVIF nooit direct als de <img>-src. Als je de patronen uit sectie 4 volgt, ben je al beschermd.

7. De spiekbrief voor 2026

Scenario	Primair	Fallback	Encoder
Statische marketingpagina’s	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp in CI
Blogposts en documentatie	WebP q75	JPEG q80	gratis afbeelding comprimeren (handmatig) of Sharp (build)
Gebruikersuploads	WebP (client-side)	JPEG (browser zonder WebP-codering)	browser-image-compression + server-side Sharp voor AVIF
HDR / professionele fotografie	AVIF 10-bits q70	(geen: laat SDR-fallback weg of sla AVIF helemaal over)	cavif + libavif HEIF-modus
Realtime CDN-aflevering	Onderhandeld (AVIF of WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Twee dingen om te controleren voor je live gaat. Zet altijd width en height op de <img> om CLS te voorkomen. En verifieer de productie-Content-Type-header op minstens één AVIF-respons; een kapotte MIME-config sloopt AVIF in productie stilletjes vaker dan welke andere fout uit deze lijst dan ook.

FAQ

Heb ik in 2026 nog een JPEG-fallback nodig?

Ja. AVIF bereikt grofweg 93% van de wereldwijde gebruikers en WebP zo’n 97%. Daardoor blijft een kleine maar reële groep over (oude Edge, Firefox onder 93, iOS vóór 16.4 plus de buggy zone iOS 16.0–16.3) die JPEG nodig heeft. Laat JPEG alleen vallen als je analytics effectief geen verkeer uit die browsers tonen en je dat ook kunt aantonen.

Hoe houd ik CI-builds snel als AVIF-codering traag is?

Er zijn drie aanpakken die werken. Gebruik cavif --speed 6 of hoger (standaard 4) om ~5% grootte in te ruilen voor ~3× snelheid. Parallelliseer over cores met GNU parallel of de worker-pool van je build-tool. En cache op contenthash, zodat ongewijzigde bronafbeeldingen de encoder volledig overslaan. Samen brengen deze maatregelen de AVIF-buildtijd meestal onder de oude single-threaded basis van WebP.

Is WebP echt sneller met decoderen dan AVIF?

Ja. libwebp decodeert grofweg 2–3× sneller dan libavif, en het gat groeit op zwakkere mobiele apparaten. Als je prestatieknelpunt decoderen is (een lange afbeeldingsgalerij op een budget-Android-toestel bijvoorbeeld) in plaats van het netwerk, is WebP het betere primaire formaat. Voor de meeste webverkeer overheerst de netwerkwinst en wint AVIF totaal nog steeds.

Kunnen iPhone-gebruikers AVIF zien?

iPhones met iOS 16.4 (maart 2023) of nieuwer ondersteunen AVIF native in Safari. Apparaten op iOS 16.0–16.3 hebben een gedocumenteerde decode-bug die Safari op bepaalde AVIF-bestanden kan laten crashen; oudere iOS-versies ondersteunen AVIF helemaal niet. Lever altijd een WebP- of JPEG-fallback in <picture> zodat getroffen gebruikers iets zien.

Moet ik `<picture>` of Accept-header-onderhandeling gebruiken?

Kleinere projecten varen wel bij expliciete <picture>-markup: het gedrag is deterministisch, je kunt lokaal debuggen en het kost misschien 80 bytes HTML extra per afbeelding. Drukbezochte sites winnen met Accept-onderhandeling aan de CDN-kant: één URL per afbeelding, automatische formaatupgrades en het CDN cachet elk formaat apart. Een gangbare hybride is <picture> voor app-UI en CDN-onderhandeling voor marketingassets.

Waarom werd mijn PNG groter na conversie naar WebP?

Bijna altijd omdat de bron-PNG al agressief was geoptimaliseerd door pngquant, oxipng of ZopfliPNG, en de Canvas-encoder van de browser die tools niet kan evenaren. Hercodeer vanaf het origineel (Photoshop-export, master uit je designtool, RAW) in plaats vanaf de geoptimaliseerde PNG. Is de geoptimaliseerde PNG je enige bron, dan is het origineel al bijna optimaal: laat het met rust.

Ondersteunt AVIF transparantie?

Ja. AVIF ondersteunt een volledig 8- tot 12-bits alphakanaal en codeert alpha doorgaans compacter dan WebP. Een transparante PNG-illustratie geconverteerd naar AVIF krimpt meestal 50–70%, tegen 30–40% als WebP. AVIF is de sterkste vervanger voor transparante PNG in elke context die geen pixelnauwkeurige lossless output eist.

Kunnen browsers AVIF native coderen via toBlob(‘image/avif’)?

Op dit moment alleen Chrome 99+. Safari en Firefox kunnen AVIF wel decoderen, maar per mei 2026 niet via Canvas-API’s coderen. Voor AVIF-codering aan de clientzijde heb je vandaag WebAssembly-bibliotheken zoals libavif-wasm of jsquash nodig, die 1–2 MB aan payload toevoegen. De meeste productiestacks comprimeren in de browser naar WebP en laten AVIF-generatie over aan een serverworker.