Resize een WebP Afbeelding
Drop een WebP hier en een WebP komt terug in de nieuwe grootte — de tool verandert nooit van formaat. Beide varianten van het formaat decoderen goed, zowel verliesgevend als verliesloos, en transparantie blijft onaangetast tijdens het resamplen. Twee dingen zijn belangrijk om te begrijpen voordat je begint: de kwaliteitsregelaar bepaalt stilletjes welke variant je terugkrijgt, en geanimeerde WebP-bestanden verliezen hun animatie zonder enige waarschuwing. Beide worden hieronder behandeld.
De regelaar kiest verliesgevend of verliesloos — stilletjes
Je uitvoer wordt geschreven door de eigen WebP-encoder van de browser, en de kwaliteitsregelaar is de enige instructie die het ontvangt. In Chromium-gebaseerde browsers produceert 100 op die regelaar een verliesloos gecodeerd bestand; elke lagere waarde produceert een verliesgevend bestand. De standaard is 90, wat betekent dat een verliesloze WebP die is verkleind met de standaardinstellingen verliesgevend terugkomt.
Of dat belangrijk is, hangt af van de afbeelding. Een foto zal het verschil niet tonen en zal dramatisch kleiner zijn als verliesgevend. Een vlakke kleurillustratie, een logo met fijne randen, of iets dat je van plan bent te blijven bewerken, verdient de regelaar op 100 zodat de codering exact blijft. Een bron die al verliesgevend was, wint niets van 100 — de schade van de eerste codering zit in de pixels — maar het voorkomt wel dat er een tweede ronde aan wordt toegevoegd.
Geanimeerde WebP is afgevlakt, en niets waarschuwt je
Deze tool verkleint stilstaande beelden. Wanneer een geanimeerd bestand binnenkomt, wordt alleen het eerste frame gedecodeerd en verkleind; elk ander frame wordt weggegooid. Voor geanimeerde GIF's leest de tool de bestandsstructuur, merkt de extra frames op en plaatst een melding op de resultaatkaart. Voor WebP bestaat er geen gelijkwaardige controle — een geanimeerde WebP gaat erin, een stilstaande enkelvoudige frame WebP komt eruit, en de interface zegt niets.
Dus de mislukking is stil, en het is de moeite waard om jezelf te beschermen: als een WebP afkomstig is van een sticker, een schermopname of een geconverteerde GIF, speel het dan af voordat je het verkleint en inspecteer de uitvoer daarna. Om een animatie te verkleinen en deze bewegend te houden, gebruik software die voor animatie is gebouwd — exporteer de frames, schaal ze en stel ze weer samen.
Waar het verkleinde bestand wel en niet werkt
Compatibiliteit is een opgelost probleem in browsers: elke huidige engine — Chrome, Safari, Firefox, Edge — heeft WebP al jaren gedecodeerd, dus een verkleind bestand is overal op het web veilig. Google's gepubliceerde vergelijkingen geven aan dat verliesgevende WebP ongeveer 25 tot 34% kleiner is dan equivalente JPEG's, en verliesloze WebP ongeveer 26% kleiner dan PNG, wat de reden is waarom het formaat de moeite waard is om te behouden wanneer de bestemming het toelaat.
De obstakels bevinden zich buiten de browser: oudere desktopafbeeldingsweergaven, sommige bedrijfsuploadformulieren en printworkflows kunnen de extensie nog steeds weigeren. Wanneer je er een tegenkomt, verklein hier eerst en verander de container met de afbeeldingsconverter daarna — de pixels zijn al goed, dus de conversie is de enige resterende stap, en het resample-aantal blijft op één.
Veelgestelde Vragen
Kan dit mijn WebP in een JPG omzetten tijdens het verkleinen?
Nee — er is geen optie voor uitvoerformaat ergens in deze tool; het formaat dat erin gaat, is het formaat dat eruit komt. Doe de verkleining, geef het bestand dan aan de afbeeldingsconverter voor de containerwijziging.
Waarom stopte mijn geanimeerde WebP met bewegen?
Omdat alleen het eerste frame wordt gedecodeerd en verkleind; de rest wordt weggegooid, en in tegenstelling tot GIF's wordt er geen melding weergegeven voor WebP. Als de animatie belangrijk is, is dit de verkeerde tool voor dat bestand.
Is de transparantie veilig in een verliesgevende WebP?
Ja — het formaat codeert het alpha-kanaal afzonderlijk van de kleurgegevens, en het blijft schoon tijdens een verliesloze opslaan, zodat uitgesneden randen intact blijven, zelfs wanneer de omringende kleuren zijn gecomprimeerd.
De verkleinde WebP is groter dan mijn origineel. Waarom?
Je bron was waarschijnlijk harder gecodeerd dan de 90 van de regelaar, of je hebt de afbeelding vergroot. Verlaag de kwaliteit, of laat de compressor bytes eruit persen zonder de afmetingen te veranderen.
Overleeft er metadata de verkleining?
Nee — het resultaat wordt opnieuw opgebouwd uit de gedecodeerde pixels, dus EXIF- en kleurprofielen worden achtergelaten. Bewaar het bronbestand als je nodig hebt wat de header droeg.