Is WebP eigenlijk kleiner dan JPG voor website-afbeeldingen?

We vergeleken JPG, WebP en AVIF op dezelfde 538,6 KB foto met dezelfde schuifregelaar, en JPG won. Dit is waarom dat gebeurt en wat de eerlijke vergelijking laat zien.

August 9, 2026

Elke gids vertelt je dat WebP ongeveer 30% kleiner is dan JPG bij gelijke kwaliteit. De eigen studie van Google is waar dat cijfer vandaan komt. We hebben de vergelijking uitgevoerd op onze eigen compressor met één 3840x2160 foto, texture.jpg van 538,6 KB, en op dezelfde schuifpositie won de JPEG: 286,1 KB tegen 290,3 KB voor WebP. AVIF, het formaat dat beide zou moeten verslaan, kwam uit op 312,7 KB.

Er was niets kapot. De drie formaten lezen die schuifregelaar anders, en een van hen doet dat opzettelijk. Zodra je weet welke, draait het resultaat terug naar wat je zou verwachten, en krijg je een gewoonte die het waard is om mee te nemen naar welk hulpmiddel je ook al gebruikt.

Waarom kwam WebP groter uit dan JPG bij dezelfde schuifregelaar?

Onze compressor heeft een eigenaardigheid die veel tools delen en bijna geen van hen noemt. Wanneer het uitvoerformaat JPEG is en de invoer al een JPEG was, leest het de kwantisatietabellen uit het bronbestand, schat de kwaliteit waarmee dat bestand is opgeslagen, en vermenigvuldigt vervolgens je schuifregelaar met die schatting. Een bron die 60 scoort met de schuifregelaar op 80 wordt gecodeerd op 48. WebP en AVIF krijgen geen dergelijke behandeling, dus 80 betekent 80 en de encoder doet wat hem is opgedragen. Die run aan de bovenkant was JPEG op een effectieve 48 tegen WebP op een letterlijke 80. Een bestand dat harder is gecomprimeerd is kleiner.

De herschaling verdient zijn plaats. Het opnieuw coderen van een al lossy JPEG op 80 wanneer het geschreven is op 60 voegt bytes toe zonder enige detail terug te voegen, dus we beschouwen de schuifregelaar als een fractie van wat er nog in het bestand zit. Het diepere probleem behoort tot JPEG zelf: de specificatie slaat ruwe kwantisatietabellen op en slaat nooit een kwaliteitsnummer op, dus 75 in Photoshop, 75 in MozJPEG en 75 in een of andere PHP-script zijn drie verschillende bestanden. Het overeenkomen van het nummer op twee schuifregelaars en het noemen van een eerlijke test werkt niet.

Hoe zien de formaten eruit als je ze goed vergelijkt?

Bij 63 schrijft WebP 200,6 KB uit die 538,6 KB bron. AVIF bij dezelfde instelling gaat naar 186,9 KB, en 63 is wat onze slimme modus toch kiest voor AVIF, dus het is geen nummer dat we hebben gekozen om het formaat te flatteren. Vergelijk eerst de uitvoerformaten, open dan beide bestanden op volledige grootte en beslis welke je kunt verdragen. Dat is de vergelijking die het waard is.

Moet ik dan gewoon AVIF gebruiken?

Op bytes wint AVIF. Op geduld verliest het. Het coderen van dat 3840x2160 frame naar AVIF duurde ongeveer 10 tot 11 seconden in de browser, terwijl JPEG en WebP onmiddellijk terugkwamen. Dit alles is WebAssembly dat op je eigen machine draait, dus dat is je laptop die AV1 intra-codering doet, en de kosten schalen met het aantal pixels. Er is een tweede vangst die het waard is om te weten: als de WASM-encoder faalt, vallen we terug op de canvas-encoder van de browser, en canvas kan JPEG, PNG en WebP schrijven, maar heeft helemaal geen AVIF-pad. Voor een grote batch, aanbevelt Google de native avifenc-tool boven WebAssembly-builds, en wat tien AVIF-coderingen in één tab je kosten wordt ook gemeten.

Wat verlies ik als ik een JPG naar een WebP omzet?

Drie concrete dingen. Metadata gaat als eerste: comprimeren of converteren decodeert de afbeelding naar ruwe pixels en codeert deze opnieuw, dus EXIF, GPS-coördinaten, het ICC-profiel en de ingesloten miniatuur zijn allemaal verdwenen uit de uitvoer. Oriëntatie overleeft, omdat de browser deze toepast tijdens het decoderen. Als je de datum van opname nodig hebt, bewaar dan het originele bestand. En een lossy JPG dat opnieuw is gecodeerd als lossy WebP is een tweede generatie van verlies gestapeld op de eerste, dus doe het één keer vanaf de beste bron die je hebt.

Chroma is het tweede verlies. Lossy WebP is vastgelegd op 4:2:0 subsampling, met geen 4:4:4 optie ergens in het formaat, dus een screenshot van syntaxis-gehighlightte code of een logo dat op verzadigd rood zit, kan er slechter uitzien in WebP dan in een JPEG van hetzelfde gewicht. Foto's geven er niet om. Rendering is de derde: een progressieve JPEG schildert vroeg een ruwe volledige afbeelding en scherpt aan naarmate de bytes binnenkomen, en WebP heeft geen progressieve modus, dus een grote laat niets zien totdat er genoeg van is aangekomen. Op een heldere afbeelding over een zwakke verbinding verandert dat hoe snel de pagina aanvoelt, zelfs als het bestand kleiner is.

Wint WebP nog steeds als de afbeelding transparantie heeft?

JPEG kan geen transparantie doen. Er is geen alpha-kanaal in enige JPEG-modus, dus voor een logo of een uitsnede is de echte wedstrijd PNG tegen WebP, en de zaak voor elk van die twee formaten wordt gemeten op dezezelfde bestanden. Onze PNG-nummers stellen de lat die je moet overtreffen: alpha.png op 900x606 en 942,4 KB kwam neer op 383,9 KB via lossless oxipng op niveau 3, en naar 98,3 KB zodra imagequant het reduceerde tot een palet, wat 90% korting is met de transparantie intact. WebP slaat zijn alpha verliesloos op, zelfs binnen een lossy bestand, zodat uitsnede-randen schoon blijven, ongeacht de manier. Als je de uitsnede in de eerste plaats maakt, schrijft onze achtergrondverwijderaar altijd PNG met alpha, en die PNG kan daarna rechtstreeks in de compressor gaan.

Welke moet ik eigenlijk op de site zetten?

Verzend WebP voor foto's. Elke huidige browser decodeert het, inclusief Safari, en de besparingen zijn echt zodra je stopt met het vergelijken van schuifgetallen. Houd JPG waar het bestand moet openen in oude software, of waar een grote heldere afbeelding meer profiteert van progressieve rendering dan van 30 KB. MDN's gids voor afbeeldingsformaten is de referentie om te controleren voordat je een hele bibliotheek aan één formaat toewijst.

Controleer eerst de pixels. Een 3840px foto is vier keer breder dan een 960px inhoudskolom ooit zal weergeven, en geen codec geeft je terug wat een resize gratis oplevert, dus de resizer met zijn 25/50/75 presets is één klik en verslaat meestal het formaatargument volledig. De kwaliteitsladder is ook belangrijker dan het formaat. Diezelfde texture.jpg ging naar 212,4 KB op 60 en 131 KB op 30, en de slimme modus settlede op 286,1 KB, 47% korting, zonder je iets te vragen.

Hoe voer ik deze test uit op mijn eigen afbeelding?

Open de compressor, drop je foto erin en schakel over naar handmatig. Kies JPG, noteer de grootte. Schakel de formaat dropdown naar WebP op diezelfde schuifregelaar en noteer die. Trek dan de WebP-schuifregelaar naar beneden totdat de twee bestanden binnen een paar KB van elkaar liggen, en bekijk ze naast elkaar op volledige grootte, want dat is de enige vergelijking die je iets vertelt. Batches zijn beperkt tot 10 bestanden en 50 MB. Als je de schuifregelaar helemaal wilt overslaan, encodeert JPG naar WebP op een vaste kwaliteit van 80 zonder herschaling, WebP naar JPG gaat de andere kant op met transparantie gematteerd op wit, en de PDF-wandelgids behandelt de ene conversie die bestanden groter maakt.