Geef een AVIF aan een tool die WebP wil

Maak een WebP van je AVIF zodra een platform bij AVIF tegenstribbelt maar PNG te veel van het goede zou zijn.

of sleep de afbeelding hierheen

Een AVIF tot een WebP maken

Een AVIF tot een WebP maken

Zet een AVIF in het uploadvlak of tik om er een te zoeken. De browser decodeert de AVIF zelf en slaat de pixels via de eigen functie opnieuw op als WebP. Beide helften zijn native, dus er is geen module om binnen te halen en geen pauze om op te warmen. De meeste foto's in een desktopbrowser zijn binnen een seconde klaar. Wanneer de WebP klaar is, zet de uitlezing de oorspronkelijke AVIF-grootte naast de verse WebP-grootte. Tik op Downloaden om het onder de oorspronkelijke basisnaam met een .webp-extensie te houden. Vanaf daar is het bestand klaar om naar elk platform te gaan dat het formaat neemt, zonder tussenstap.

Waarom weegt de WebP meer?

Waarom weegt de WebP meer?

AVIF is in 2026 het slankste gangbare beeldformaat dat er is en landt bij dezelfde zichtbare kwaliteit meestal 20 tot 25 procent onder WebP. Van AVIF naar WebP gaan ruilt een strakker formaat voor een losser, dus de uitvoer groeit vanzelf. Niets daarvan wijst op een fout in de omzetting. Je kiest het met opzet, en geeft een kruimeltje efficiëntie weg voor het veel ruimere onthaal dat WebP geniet over tools en platforms. De WebP die eruit rolt, ligt nog altijd ruim onder een PNG van dezelfde opname. Afgemeten aan het bereik dat je wint onder de systemen die AVIF nog niet hebben ingehaald, is dat extra gewicht een klein rekeningetje.

AVIF of WebP, welke houden

AVIF of WebP, welke houden

Blijf bij AVIF waar je de hele leveringsketen voert, je bezoekers actuele browsers gebruiken en elke kilobyte telt. Grijp naar WebP op het moment dat de andere kant AVIF weigert: WordPress- en Shopify-bibliotheken op verouderde uploadcode, sociale sites die beelden op externe servers met oudere codecs opnieuw koken, nieuwsbriefplatforms die hun beeld vooraf bewerken, bejaarde leveringsopstellingen, oudere designsuites en elke plek waar AVIF al is afgewezen. Je geeft geen kwaliteit op die iemand zou opvallen, want WebP bij vrijwel verliesvrije instellingen evenaart de AVIF bij gewone formaten. De beloning is een ticket in elk systeem dat met AVIF nog achterloopt.

Komt de transparantie erover?

Komt de transparantie erover?

Ja, dat doet ze. Een alphakanaal leeft in WebP net als in AVIF, dus de omzetting houdt elke doorzichtige pixel precies waar hij was. Een logo met schaduw, een productuitsnede met uitgevloeide randen, een afgeronde interfacetegel, ze bereiken allemaal de WebP en dragen het masker dat ze in de AVIF hadden. Dat is de afstand tussen dit en een uitstapje naar JPG, dat geen alphakanaal bezit en een effen vulling over de heldere zones legt. De kleurvlakken en het alphamasker slaan beide op bij vrijwel verliesvrije instellingen, dus de randen blijven scherp en de transparantie wordt nooit troebel en klapt nooit om in een gedeeltelijke vulling. Vooraf afvlakken is nooit nodig.

Waar WebP werkt

Waar WebP werkt

Zo goed als elke actuele browser opent WebP: Chrome, Firefox, Safari, Edge en de grote mobiele doen het allemaal. De dekking wereldwijd overstijgt 97 procent. Het punt dat hier meer telt, is bereik voorbij de browser, waar WebP veel verder reist dan AVIF. Mailprogramma's die AVIF afwijzen, nemen vaak WebP zodra de server het heeft voorgekauwd. Contentsystemen die AVIF-uploads blokkeren, wuiven WebP meestal door. Designtools die AVIF missen, lezen WebP toch. Wanneer een beeld over meerdere systemen springt voordat het neerstrijkt, is WebP momenteel het rustiger middenformaat. Voor puur browser-naar-browserwerk drukt AVIF harder, maar WebP's onthaal over niet-browsertools is de doorslaggevende kracht.

Waar het werk gebeurt

Waar het werk gebeurt

Dat hangt af van hoeveel bestanden je meebrengt. Een losse afbeelding wordt volledig in de eigen beeldengine van de browser bewerkt: de AVIF wordt gedecodeerd en de WebP daar ter plekke weggeschreven, zonder dat er iets ergens heen gaat. Open het DevTools, blijf op het tabblad Netwerk, zet een bestand om, en geen enkele uitgaande aanvraag voor de afbeelding duikt de hele tijd op. Een stapel bestanden gaat de andere kant: de set gaat omhoog naar onze server, die het coderen laat draaien en het pakket sluit, en de download wordt rond de 2 uur weggeveegd. We bewaren geen account en geen kopie van je foto voorbij die korte strook. Dus een omzetting blijft van begin tot eind bij jou, terwijl een set op onze server wordt bewerkt en daarna opgeruimd, zonder dat er iets van jouw materiaal achterblijft.

Hoe het werkt

  1. Voeg je AVIF toe

    Sleep de AVIF in het uploadvlak, of tik erop om een kiezer te openen en er een van je apparaat te grijpen om het op gang te brengen.

  2. Laat het afmaken

    De browser decodeert de AVIF zelf en bouwt een WebP. Beide helften zijn native, dus er laadt vooraf niets en de ronde blijft vlot.

  3. Werp een blik op de groottes

    De uitlezing zet de AVIF-brongrootte naast de WebP-uitvoer. Reken erop dat de WebP ruwweg 20 tot 25 procent groter loopt.

  4. Hou de WebP

    Tik op Downloaden om het bestand onder de oorspronkelijke basisnaam met een verse .webp-extensie op je apparaat te bewaren.

Blijf omzetten

Pers een WebP weer terug naar AVIF waar de andere kant het ondersteunt, of ga helemaal door naar PNG voor vol verliesvrij bereik.

Veelgestelde vragen

Wat levert AVIF naar WebP op?

WebP glipt in meer leden dan AVIF. Mailprogramma's, trage inlees in sommige WordPress- en Shopify-bouwsels, sociale kanalen die het beeld op een verre server vermalen, stokoude uitleveringen en bildtools zonder AVIF nemen allemaal WebP zonder morren. AVIF bewaar je voor de strakste bestanden. WebP haal je tevoorschijn wanneer het lid aan de overkant AVIF nog niet heeft kunnen lezen. Wat drijft is doorkomen, niet bytes sparen, en de betaling is een tikje zwaarder bestand.

Verslaat WebP de AVIF op grootte?

Nee. AVIF loopt bij gelijke zichtbare scherpte doorgaans een vijfde tot een kwart kleiner dan WebP. AVIF naar WebP brengen baart een wat groter bestand, nooit een kleiner. Wil je het kleinst denkbare bestand en leest de ontvanger AVIF, hou AVIF. Haal WebP enkel tevoorschijn waar de ontvanger erop staat. Toch blijft de WebP een flink stuk onder een PNG van hetzelfde beeld, dus het houdt stand als een net lid wanneer het formaat moet kloppen.

Wordt transparantie door de omzetting gehouden?

Ja, volledig. Omdat een alphakanaal in AVIF en in WebP allebei bestaat, schuiven de heldere pixels onberoerd mee. Er is geen afvlakken en geen vulling die zich achter het onderwerp wurmt. JPG is het tegendeel, helemaal zonder alpha, dus het zou elke doorzichtige plek tot een vlakke toon maken. Je logo's, je uitsnedes, je interfacetegels houden allemaal zachte randen en ronde hoeken door de omzetting, klaar om over elke achtergrond te liggen die je kiest.

Kost de omzetting kwaliteit?

Nauwelijks iets. Het opslaan als WebP werkt bij een vrijwel verliesvrije instelling die op foto's rond 44 dB PSNR leest, wat het oog bij normale formaten niet van de AVIF-bron kan scheiden. Er is één opslagronde, dus het resultaat is technisch met verlies, maar artefacten blijven op natuurlijke beelden onzichtbaar. Voor grafiek met heel scherpe randen of harde kleursprongen bestudeer de uitvoer van dichtbij, want die zones voelen elke verschuiving in compressie scherper dan rustige fotografische inhoud.

Hoe lang loopt de omzetting?

Onder een seconde voor de meeste foto's in een desktopbrowser. Geen helft hoeft eerst te laden, want het inlezen van AVIF en het wegleggen als WebP zitten allebei in actuele browsers. Een doorsnee opname van 2 megapixel landt op Chrome rond 100 tot 200 milliseconden, en zelfs forse 4K-beelden klappen meestal binnen een seconde dicht. Zet de tegenkant ernaast, het bakken van AVIF uit een WebP, dat een zwaar deel moet wekken en veel meer rekenwerk moet vermalen voordat er iets uit rolt.

Welke browsers lezen WebP?

Zowat elke moderne browser doet het, en al jaren. Chrome opende WebP bij versie 23, Firefox bij 65, Safari bij 14 en Edge bij 18, terwijl de mobiele builds dezelfde nummers volgen. De wereldwijde WebP-dekking loopt voorbij 97 procent. Praktisch gezien leest elke browser die in 2026 nog echt in gebruik is WebP haast zonder uitzondering. De overgebleven hoekjes zijn Internet Explorer en heel oud Safari op iOS 13 of eerder, die in het verkeer amper nog opduiken.

De details

Notities van het team over vakmanschap, formaten en de kleine beslissingen achter een goede ronde uitsnede.

Hoe de AVIF-compatibiliteit er in 2026 bij staat
AVIF ruimde tegen 2026 wereldwijd zo'n 94,3 procent van de browsers op, maar de browserdekking vertelt maar het halve verhaal. Een dikke brok van het beeldgebruik gebeurt weg van browsers: mailprogramma's die ingebedde beelden schilderen, designtools die bestanden openen om te bewerken, contentsystemen die uploads keuren en opnieuw bewerken, leverings-beeldpaden, documenteditors die beeld insluiten, en sociale platforms die beelden bij het uploaden doorkauwen. Over de meeste van die niet-browsersystemen loopt AVIF de browseropname met een brede kloof achterna. Gmail, Outlook en de meeste zakelijke mailers schuiven beelden nog door oudere paden die AVIF afwijzen. Adobe Creative Cloud nam AVIF pas op in zijn late versies van 2024. Veel WordPress-opstellingen op oudere beeldplug-ins blokkeren AVIF bij het uploaden nog. WebP daarentegen is over bijna al deze al jaren welkom. AVIF naar WebP is de brug over die niet-browsergrond.
Waarom deze richting de vlotte is
AVIF naar WebP haalt de omgekeerde kant in dankzij hoe de codecs zitten. Het decoderen van AVIF leunt op een native browserdecoder die op actuele apparaten hardwareversnelling binnenhaalt. Het opslaan als WebP gebruikt de eigen WebP-functie van de browser, op de meeste platforms ook hardwaregesteund. Geen van beide kanten hoeft een zware module te laden, en dat is precies het knelpunt bij het opslaan van AVIF. De functie voor AVIF-uitvoer is log en wil per sessie zo'n seconde om op te starten. AVIF naar WebP omzeilt dat allemaal. Het pad decodeert en slaat daarna op via native wegen, en de volle heen-en-weer voor een foto van 2 megapixel wikkelt zich op elke moderne desktop of laptop ruim binnen een seconde af. Dat maakt het paar geschikt voor interactief gebruik, waar mensen binnen een seconde een antwoord verwachten.
Wat het ene opnieuw opslaan werkelijk kost
AVIF naar WebP loopt één keer opnieuw opslaan. De AVIF kwam aan met wat eigen verliesgevende compressie. Hem decoderen levert pixels die die verliesgevende oorsprong weerspiegelen. Het opslaan als WebP legt dan zijn eigen compressie over die pixels bij een vrijwel verliesvrije instelling die is afgesteld op kwaliteit 85. Op dat niveau leest de uitvoer op gewoon fotomateriaal rond 44 dB PSNR. Voor iemand die een foto op normale grootte bekijkt, zien de AVIF-bron en de WebP-uitvoer er gelijk uit. Voor grafiek met heel fijne letters op kleine formaten, pixelexacte iconen of hardkantige kleurblokken kan het gestapelde effect van twee verliesgevende rondes bij nauwkeurig kijken zwakke verschillen tonen. Voordat je een hele bibliotheek aan de ruil toevertrouwt, rijd een representatief monster op volle zoom over je meest kwaliteitsgevoelige beelden.
Het alpha door de ronde volgen
AVIF bergt zijn transparantie op een aparte laag op die met AV1-intraframewerk is gecodeerd. Decodeer een AVIF en de browser reikt een kleurbuffer plus een alphamasker zij aan zij aan. De omzetting brengt het paar bij volle transparantie samen en houdt elke deels heldere pixel. Het opslaan als WebP schrijft dan een verliesgevende WebP waarvan het alpha rijdt op een kanaal dat met WebP's verliesvrije methode speciaal voor het alphavlak is gecodeerd. Het gevolg is dat het alphamasker in de uitgevoerde WebP verliesvrij wordt gehouden tegen het alpha dat de browser uit de AVIF trok. Zachte verlopen en uitgevloeide randen leven door. Het enige alphaverlies in het spel is wat de eigen AVIF-codering eerder neerlegde. Schone alpharanden in de bron betekenen schone alpharanden in de WebP, masker klaar om overal samengesteld te worden.
WebP tegen de andere opties zetten
Om een AVIF te laten werken in een systeem dat hem niet kan lezen, staan drie echte keuzes: WebP, PNG of JPG. JPG is fout voor alles met transparantie, want het bezit geen alpha en vlakt het af tot een effen kleur. PNG maakt het zwaarste bestand, vaak drie tot tien keer de AVIF-grootte, en verdient zijn plek alleen wanneer je een verliesvrije tussenkopie nodig hebt of de andere kant ronduit PNG eist. WebP neemt het midden: universeel modern bereik, transparantie intact en een bestand meestal 20 tot 25 procent boven de AVIF in plaats van de 300 tot 1000 procent die een PNG erbovenop legt. Voor elke compatibiliteitsruil die geen verliesvrije uitvoer vraagt, is WebP het middenformaat dat past.
Eentje lokaal, een set op de server
Dit paar heeft twee modi, gekozen op de grootte van de klus. Een eenzame AVIF wordt volledig in je browser via native wegen gedecodeerd en als WebP herschreven, dus voor een enkel bestand gaat er niets omhoog, wat het DevTools schraagt met geen enkele uitgaande aanvraag na het laden van de pagina. Dat is de juiste strook voor iets snels en voor vertrouwelijke klantframes, eigen productopnames, of scans die je liever op je eigen apparatuur houdt. Een stapel bestanden draait op onze server, want bundelen, in een zip sluiten en een set afleveren is precies de kracht van een server: de bestanden gaan omhoog, worden gecodeerd, ingepakt, en komen terug als een download, die zich rond de 2 uur opruimt, zonder account en zonder iets dat lang bewaard blijft. De simpele lezing is dat een omzetting stil op het apparaat blijft liggen, terwijl een set op afstand wordt bewerkt maar alleen voor het korte venster bewaard dat het ophalen kost.