Beskär

Beskär bild Beskär bild i cirkel

Optimera

Komprimera bild Förstora bild Ta bort bakgrund

Redigera

Ändra bildstorlek

Konvertera

Övriga

JPG till PDF

Räck en AVIF till ett verktyg som vill ha WebP

Gör en WebP av din AVIF så fort en plattform krånglar med AVIF men PNG vore i mesta laget.

eller dra bilden hit

Om det här verktyget

Koda om en AVIF till WebP på ett kick. Att konvertera en bild kör precis här i webbläsaren, där den avkodar AVIF:en på egen hand och skriver om pixlarna till WebP med den inbyggda kodaren, så en ensam fil har inget att skicka och de flesta foton blir klara på under en sekund. Att konvertera en näve ihop tar en annan väg: uppsättningen skickas till vår server för att göra jobbet och den färdiga nedladdningen raderas inom ungefär 2 timmar. Transparensen följer med i båda fallen, eftersom AVIF och WebP var för sig bär en full alfakanal, och urklipp och staplade lager kommer in i WebP:n iförda samma mask de hade i AVIF:en. Utdatan kommer ut lite tyngre, oftast 20 till 25 procent, för AVIF packar tätare än WebP vid samma kvalitet. Det här är ett drag för räckvidd, inte för storlek. WebP slinker in i e-postprogram, äldre designsviter, uppladdningsvägar i sociala medier och innehållssystem som ännu inte lärt sig AVIF.

Att göra en WebP av en AVIF

Att göra en WebP av en AVIF

Dra in en AVIF i rutan eller peka för att leta rätt på en. Webbläsaren tolkar AVIF-filen på egen hand och lägger om bildpunkterna till WebP med det verktyg den bär med sig. Inget av stegen kräver att något hämtas, och inget behöver gå varmt först, så ett vanligt foto i en stationär webbläsare är färdigt inom någon sekund. När WebP är klar visar raden hur den gamla AVIF-storleken och den nya WebP-storleken förhåller sig. Tryck Ladda ner, så hamnar filen hos dig med samma stam i namnet och .webp efter punkten. Då går den att lämna vidare med en gång till vad som helst som tar emot formatet.

Varför väger WebP mer?

Varför väger WebP mer?

AVIF är 2026 det smäckraste gängse bildformatet som finns och landar vid samma synliga kvalitet oftast 20 till 25 procent under WebP. Vägen från AVIF till WebP byter ett stramare format mot ett lösare, så utdatan växer av sig själv. Inget av det pekar på ett fel i omvandlingen. Du väljer det med flit och ger bort en smula effektivitet mot det långt bredare mottagande WebP åtnjuter bland verktyg och plattformar. WebP-filen som rullar ut ligger ändå klart under en PNG av samma tagning. Mätt mot den räckvidd du vinner bland systemen som ännu inte hunnit ifatt AVIF är den extra vikten en liten nota.

AVIF eller WebP, vilken behålla

AVIF eller WebP, vilken behålla

Stanna på AVIF där du för hela leveranskedjan, dina besökare kör aktuella webbläsare och varje kilobyte räknas. Grip efter WebP i stunden då andra änden vägrar AVIF: WordPress- och Shopify-bibliotek på föråldrad uppladdningskod, sociala sajter som kokar om bilder på fjärrservrar med äldre kodare, nyhetsbrevsplattformar som förbehandlar sina motiv, ålderstigna leveransuppställningar, äldre designsviter och varje ställe där AVIF redan avvisats. Du ger inte upp någon kvalitet som någon skulle märka, då WebP vid nästan förlustfria inställningar matchar AVIF vid vanliga storlekar. Belöningen är en biljett in i varje system som släpar efter med AVIF.

Kommer transparensen över?

Kommer transparensen över?

Ja, det gör den. En alfakanal lever i WebP precis som i AVIF, så omvandlingen håller varje genomskinlig pixel exakt där den var. En logotyp med skugga, ett produkturklipp med tonade kanter, en rundad gränssnittsbricka, alla når WebP och bär masken de hade i AVIF. Det är avståndet mellan detta och en avstickare till JPG, som inte äger någon alfakanal och lägger en enfärgad ifyllnad över de klara partierna. Färgplanen och alfamasken sparar båda vid nästan förlustfria inställningar, så kanterna håller skarpa och transparensen grumlas aldrig och faller aldrig över i en delvis ifyllnad. Att platta ut i förväg behövs aldrig.

Var WebP fungerar

Var WebP fungerar

Nära nog alla nutida webbläsare läser WebP rakt av: Chrome, Firefox, Safari, Edge och de tunga på mobilen. Räknat över hela världen ligger andelen ovanför 97 procent. Det viktiga här ligger ändå utanför webbläsaren, för där sträcker sig WebP mycket längre än AVIF. Brevprogram som säger nej till AVIF släpper ofta in WebP när servern hunnit förbereda den. Redaktionsverktyg som stänger ute AVIF vid inläggning öppnar oftast för WebP. Bildprogram utan AVIF tar ändå emot WebP. Ska en bild vandra genom flera led innan den vilar är WebP det tryggare mellanledet i dag. Renodlat mellan två webbläsare vinner AVIF på täthet, men WebP bär längre där verktygen ligger utanför webbläsaren.

Var jobbet sker

Var jobbet sker

Det beror på hur många filer du tar med. En ensam bild bearbetas helt i webbläsarens egen bildmotor: AVIF:en avkodas och WebP:n skrivs där på stället, utan att något går iväg någonstans. Öppna DevTools, stanna på fliken Nätverk, konvertera en fil, och inte en enda utgående begäran för bilden dyker upp hela tiden. En hög filer tar den andra vägen: uppsättningen stiger upp till vår server, som kör kodningen och stänger paketet, och nedladdningen sopas mot 2 timmar. Vi behåller inget konto och ingen kopia av ditt foto bortom den korta remsan. Så en konvertering stannar hos dig från början till slut, medan en bunt bearbetas på vår server och sedan städas, utan något av ditt material sparat efteråt.

Så fungerar det

  1. Lägg till din AVIF

    Dra AVIF-filen in i uppladdningsytan, eller tryck på den för att öppna en väljare och greppa en från enheten för att sätta i gång.

  2. Låt det bli klart

    Webbläsaren avkodar AVIF-filen själv och bygger en WebP. Båda halvorna är inbyggda, så inget laddas i förväg och varvet håller sig kvickt.

  3. Kasta en blick på storlekarna

    Avläsningen sätter AVIF-källans storlek bredvid WebP-utdatan. Räkna med att WebP går ungefär 20 till 25 procent större.

  4. Behåll WebP

    Tryck på Ladda ner för att spara filen under det ursprungliga basnamnet med en färsk .webp-ändelse på din enhet.

Fortsätt omvandla

Pressa en WebP tillbaka till AVIF där andra änden stöder det, eller fortsätt hela vägen till PNG för full förlustfri räckvidd.

WebP till AVIF AVIF till PNG

Vanliga frågor

Vad ger AVIF till WebP?

WebP slinker in i fler led än AVIF. Brevprogram, slö inläggning i somliga WordPress- och Shopify-bygg, sociala kanaler som maler bilden på fjärrserver, åldriga utleveranser och bildprogram utan AVIF tar alla emot WebP utan knot. AVIF sparar du åt de tätaste filerna. WebP plockar du fram när ledet på andra sidan inte hunnit läsa AVIF än. Det drivande är att nå fram, inte att spara byte, och betalningen är en aning tyngre fil.

Slår WebP AVIF på storlek?

Nej. AVIF brukar gå en femtedel till en fjärdedel mindre än WebP vid samma synliga skärpa. Att flytta AVIF till WebP föder en fil som är lite större, aldrig mindre. Vill du ha minsta tänkbara fil och mottagaren läser AVIF, behåll AVIF. Plocka fram WebP enbart där mottagaren pekar på det. Ändå ligger WebP en bra bit under en PNG av samma motiv, så den står sig som ett nätt val när formatet ska passa.

Hålls transparensen genom omvandlingen?

Ja, fullt ut. Eftersom en alfakanal finns i AVIF och i WebP lika väl glider de klara pixlarna med oberörda. Det finns ingen utplattning och ingen ifyllnad som tränger sig bakom motivet. JPG är motsatsen, helt utan alfa, så det skulle göra varje genomskinlig fläck till en platt ton. Dina logotyper, dina urklipp, dina gränssnittsbrickor håller alla mjuka kanter och rundade hörn genom omvandlingen, redo att läggas över vilken bakgrund du än väljer.

Kostar omvandlingen kvalitet?

Knappt märkbart. Nedläggningen som WebP rör sig på en nästan förlustfri nivå som läser kring 44 dB PSNR på foto, omöjlig att skilja från AVIF-källan med blotta ögat i vanlig storlek. Ett nedläggningsvarv finns, så slutet räknas som förlustbärande rent tekniskt, men inga spår syns på naturliga motiv. På grafik med stenhårda kanter eller tvära färgbyten lönar det sig att titta nära på slutet, för de fälten reagerar tydligare på en skiftad komprimering än ett stillsamt foto.

Hur länge löper omvandlingen?

Under en sekund för de flesta foton i en desktopwebbläsare. Ingen halva behöver ladda först, då avkodning av AVIF och sparande som WebP båda sitter inbyggda i aktuella webbläsare. En medelstor tagning på 2 megapixel landar på Chrome runt 100 till 200 millisekunder, och även rejäla 4K-rutor sluter sig oftast inom en sekund. Jämför motsatt håll, att göra AVIF ur en WebP, som måste väcka en tung funktion och tugga genom långt mer räkning innan något kommer ut.

Vilka webbläsare läser WebP?

Så gott som varje modern webbläsare gör det, och har gjort i åratal. Chrome öppnade WebP vid version 23, Firefox vid 65, Safari vid 14 och Edge vid 18, medan de mobila byggena följer samma nummer. Den världsomspännande WebP-täckningen löper förbi 97 procent. Praktiskt sett läser varje webbläsare som är i verkligt bruk 2026 WebP nästan utan undantag. De kvarvarande hörnen är Internet Explorer och mycket gammal Safari på iOS 13 eller tidigare, som knappt dyker upp i trafiken längre.

Detaljerna

Anteckningar från teamet om hantverk, format och de små beslut som ligger bakom en bra rund beskärning.

Hur AVIF-kompatibiliteten står 2026
Mot 2026 hade AVIF tagit sig in i ungefär 94,3 procent av jordens webbläsare, men siffran för webbläsare täcker bara halva fältet. Mycket av allt bildtittande ligger utanför dem: brevprogram som ritar bilder i texten, bildverktyg som plockar upp filer för redigering, redaktionsverktyg som synar och bearbetar det som läggs in, bildled i utleveransen, dokumentprogram som lägger in motiv och sociala kanaler som arbetar bilden redan vid inläggning. I flertalet av de leden ligger AVIF långt bakom den takt webbläsarna håller. Gmail, Outlook och de flesta jobbmejlar kör ännu bilden genom äldre led som nekar AVIF. Adobe Creative Cloud tog in AVIF först i sina sena utgåvor 2024. Många WordPress-bygg på gamla bildtillägg stänger fortfarande ute AVIF vid inläggning. WebP har däremot fått plats i nästan alla dessa i åratal. Att gå AVIF till WebP är spången över marken bortom webbläsaren.
Varför det här hållet är det kvicka
Att AVIF till WebP slår det motsatta hållet beror på hur de två formaten är byggda. AVIF läses av en avläsare som redan finns i webbläsaren och drar nytta av grafikkretsen på nutida enheter. WebP läggs ner med webbläsarens egen WebP-del, även den uppbackad av kretsen på flertalet enheter. Inget av leden behöver dra in en tung modul, och just den tunga modulen är vad som bromsar när AVIF ska läggas ner. Delen som tillverkar AVIF är otymplig och vill ha ungefär en sekund på sig att vakna varje gång. AVIF till WebP slipper allt det. Bilden läses och läggs ner längs inbyggda spår, och hela vändan för ett foto på 2 megapixel är överstökad gott under en sekund på vilken nutida stationär eller bärbar som helst. Därför duger paret till sådant som ska kännas direkt, där den som väntar vill ha svar inom en sekund.
Vad det enda omsparandet verkligen kostar
En vända AVIF till WebP rymmer ett enda nedläggningssteg. AVIF-filen bar redan en gnutta komprimering med förlust när den kom. Att läsa den ger bildpunkter som speglar det ursprunget. WebP-delen lägger sedan sin egen komprimering ovanpå dem på en nästan förlustfri nivå inställd kring kvalitet 85. Där läser slutbilden runt 44 dB PSNR på vanligt fotomotiv. Den som ser ett foto i vanlig storlek skiljer inte AVIF-källan från WebP-slutet. På grafik med riktigt finstilt text i smått, ikoner på pixeln eller hårda färgfält kan de två förlustvarven tillsammans visa en svag skillnad om man kikar nära. Innan ett helt bibliotek får gå igenom, prova ett tvärsnitt i full förstoring på de motiv där skärpan väger tyngst.
Att följa alfa genom varvet
AVIF lägger sin genomskinlighet på ett eget skikt kodat med AV1 inom rutan. Läs en AVIF, så lämnar webbläsaren ifrån sig dels en färgyta, dels en alfamask. Vändan lägger ihop dem vid full genomskinlighet och behåller varenda halvklar punkt. WebP-delen skriver därpå en WebP med förlust vars alfa vilar på ett skikt som kodats med WebP:s förlustfria metod just för alfat. Slutet blir att alfamasken i WebP hålls förlustfri mot det alfa webbläsaren drog ut ur AVIF. Mjuka toningar och utdragna kanter står kvar. Den enda alfaförlust som spökar är den AVIF-filens egen kodning redan satt. Är kanterna rena i källan blir de rena i WebP, masken redo att läggas in var som helst.
Att ställa WebP mot de andra valen
Ska en AVIF gå hem i ett system som inte rår på den finns tre vägar värda namnet: WebP, PNG eller JPG. JPG faller bort för allt med genomskinlighet, eftersom det inte rymmer alfa och stryker över det med en enda färg. PNG ger den klumpigaste filen, gärna tre till tio gånger AVIF:en, och försvarar sin plats först när en förlustfri mellankopia krävs eller mottagaren bara vill ha PNG. WebP håller mitten: den når brett bland nutida verktyg, behåller genomskinligheten och stannar oftast en femtedel till en fjärdedel över AVIF:en i stället för de tre till tio gånger en PNG drar på. För varje växel som inte pekar mot förlustfritt är WebP mellanledet som sitter rätt.
En lokalt, en bunt på servern
Det här paret har två lägen, valda av jobbets storlek. En ensam AVIF avkodas och skrivs om som WebP helt inuti din webbläsare längs inbyggda vägar, så för en enda fil stiger inget upp, vilket DevTools stöttar med inte en enda utgående begäran efter att sidan laddats. Det är rätt remsa för något kvickt och för konfidentiella kundrutor, egna produktbilder, eller skanningar du hellre håller på din egen utrustning. En bunt filer kör på vår server, för att gruppera, stänga i en zip och skicka ut en uppsättning är just en servers styrka: filerna stiger upp, kodas, packas, och kommer tillbaka som en nedladdning, som städas mot 2 timmar, utan konto och utan något hållet på sikt. Den enkla läsningen är att en konvertering ligger stilla på enheten, medan en bunt bearbetas på distans men hålls bara det korta fönster som hämtningen tar.