WebP 轉 AVIF 的步驟
把 WebP 拖進上傳區，或點一下來選一個檔案。檔案一到，轉換就開始，沒有另外的轉換按鈕。由於 AVIF 是最重的生成格式，單張圖片會為了最好的結果被送到我們的伺服器，AVIF 會以可下載的形式回來。小圖遠不到一秒就轉好，200 萬像素的照片約一秒，800 萬像素約幾秒。AVIF 完成後，點下載，用相同的原名和新的.avif 副檔名儲存。統計列會顯示兩個大小，下載連結會在大約 2 小時後刪除。
正在載入您的檔案…
把 WebP 轉成 AVIF，檔案更小又保留 Alpha
把 WebP 轉成 AVIF，得到小上 20 到 30 個百分點且保留透明度的照片。
正在載入您的檔案…
或將圖片拖放至此
轉換中…
0%
正在轉換您的圖片
這可能需要一分鐘左右——多個檔案會稍久一些。請保持此分頁開啟。
圖片已轉換為 AVIF
快速解答
幾次點擊就能把一張 WebP 轉成 AVIF。由於 AVIF 是最重的生成格式，為了最好的結果，繁重的工作交由我們的伺服器來做，所以轉成 AVIF 可能會把圖片送到我們的伺服器。當你一次轉換多個檔案時，伺服器一律處理這一批，下載連結會在大約 2 小時後刪除。兩種格式都是有損的，所以這是第二次有損處理，WebP 當初已經壓掉的色彩細節會再被壓一次。就照片而言，品質 85 的結果在視覺上幾乎沒有可見損失，，輸出通常比原本的 WebP 小 20 到 30 個百分點。如果你的 WebP 帶有透明背景，alpha 通道會完整保留。老實說，速度是弱點。一張 200 萬像素的照片不到一秒，800 萬像素約幾秒，更大的圖片要更久。工作階段第一次轉換可能要短暫暖機。
AVIF 比 WebP 小多少？
AVIF 建立在 現代格式 編解碼之上，在相同感知品質下檔案約比 WebP 小 20 到 30 個百分點，這是依據多組照片測試集的 與 比較得出的。在平塗色塊或硬邊的簡單圖形上差距會收窄，WebP 甚至能打平或勝出。最大的勝場在照片，而照片正是大多數現代網站頁面重量的主角。一張 的 WebP 在同等視覺品質下可能變成 noticeably smaller 的 AVIF。對已經壓得很重的 WebP 來源，省下的空間又更有限。AVIF 的瀏覽器支援現已超過全球 93 個百分點，所以對現代受眾來說需要退而求其次的情況已縮到很小一塊。
WebP 轉 AVIF 會保留透明度嗎？
會。WebP 支援 alpha 通道，AVIF 也是，轉換會把它原封不動帶過去。一張透明背景的 WebP 會轉成同樣透明背景的 AVIF，沒有白底填色、沒有色偏、沒有邊緣光暈、也沒有預乘 alpha 帶來的意外。這跟轉成 JPG 正好相反，JPG 沒有透明度，alpha 會被毀掉。如果你的 WebP 裝著去背的標誌、介面圖塊，或是放在透明畫布上的貼圖，AVIF 是個安全的去處，你不需要先把圖片填平。alpha 平面會和色彩資料一起以品質 85 處理，到了輸出時柔邊依然完好。
品質與處理速度
兩種格式都是有損的，這一對固定在品質 85。在那個設定下，照片量到，自然影像在視覺上接近無損。硬邊或平塗色塊的圖形可能出現輕微瑕疵。由於來源本來就是有損 WebP，這是第二次有損處理，WebP 已經丟掉的資訊沒辦法找回。速度則是 AVIF 壓縮效率的代價。在 Chrome 桌面版上，200 萬像素的照片不到一秒，800 萬像素約 3 秒，2,400 萬像素則要 10 到 30 秒。Firefox 大約慢四倍，手機又比桌面 Chrome 慢 3 到 5 倍。第一次處理還會付一次性的暖機。
用於投遞的 AVIF 瀏覽器支援
AVIF 現已覆蓋全球超過 93 個百分點的瀏覽器：Chrome 85 起、Firefox 93 起、Safari 16.4 起、Edge 121 起都能原生顯示。Internet Explorer、Opera Mini，以及 2022 年前的 Safari 則不行。對投遞而言，實際的結論是用一個 HTML picture 元素，AVIF 搭配 WebP 退路，就能涵蓋幾乎所有現代流量。對於剩下那幾個百分點仍要顧及的網站，把 WebP 退路留著。對受眾確定是現代瀏覽器的網站，單用 AVIF 就可行。頻寬上的省下，正是 2026 年講究效能的開發者多半採用「AVIF 優先、WebP 退路」這套作法的原因。
你的檔案在哪裡處理
AVIF 是最吃力的生成格式，所以這一對會用我們的伺服器來交付最好的結果，也就是說轉成 AVIF 可能會把你的 WebP 送到那裡。處理進行，AVIF 回來，下載連結會在大約 2 小時後刪除。當你一次轉換多個檔案時，伺服器一律接手這一批，把結果集成一個包，同樣是大約 2 小時的視窗。萬一伺服器無法使用，頁面會改為在瀏覽器裡生成單張圖片，把那一個檔案留在裝置上。我們不保留帳號、個人資料，也不保留你圖片的副本，超過這個短暫的處理視窗就沒有了。老實總結：單張 AVIF 為了品質可能在我們的伺服器上生成，一批總是這樣，之後屬於你的東西什麼都不會留下。
運作方式
-
放入你的 WebP
把 WebP 拖到上傳區，或點一下開啟檔案選擇器，從裝置裡挑一張。
-
讓它轉換
AVIF 是最重的生成格式，所以圖片會為了最好的結果被送到我們的伺服器。下載會在大約 2 小時後刪除。
-
查看檔案大小
AVIF 一好，統計列就會顯示 WebP 來源大小與 AVIF 輸出大小。照片掉個 20 到 30 個百分點是常態。
-
下載 AVIF
按下載把檔案存到裝置，沿用原本的主檔名並換成新的.avif 副檔名。
相關轉換
需要更廣的相容性時回到 WebP，或從無損的 PNG 出發省下更多空間。
常見問題
AVIF 比 WebP 好嗎？
對投給現代瀏覽器受眾的照片來說，AVIF 在壓縮上勝出：依多組照片測試集的 量測，相同感知品質下檔案通常小 20 到 30 個百分點。在平塗色與硬邊的圖形上，WebP 有競爭力，偶爾還能做出更小的檔案。兩者都支援 alpha 與動畫。如果你的受眾用現代瀏覽器，目前約全球 93 個百分點的使用者，AVIF 是更好的預設。否則就把 WebP 留作退路。
把 WebP 轉成 AVIF 會掉品質嗎？
會，一些世代損失無可避免。兩種格式都是有損的，所以把有損 WebP 以 AVIF 品質 85 再處理一次，等於多一道壓縮。照片的結果在視覺上接近無損，量到。硬邊或平塗色塊的圖形則可能出現輕微瑕疵。從有損 WebP 來源得不到真正無損的 AVIF，因為 WebP 當初捨棄的資訊，在這次轉換開始前就已經沒了。
AVIF 像 WebP 一樣支援透明度嗎？
是。WebP 與 AVIF 都支援 alpha 通道，轉換會把透明度精確帶過去，沒有白底填色、沒有色偏、也沒有邊緣光暈。這跟轉成 JPG 不同，JPG 沒有透明度，alpha 通道會被完全破壞。如果你的 WebP 有透明背景，你的 AVIF 也會有，柔邊與半透明像素都原樣保留。轉換前不需要手動填平。
WebP 轉 AVIF 要多久？
工作階段的第一次處理會花約一秒做準備。之後，200 萬像素的圖片在 Chrome 上不到一秒就好，800 萬像素約 3 秒，2,400 萬像素可能要 10 到 30 秒。Firefox 處理 AVIF 大約比 Chrome 慢四倍，所以大圖在 Firefox 上可能卡上半分鐘。手機比桌面慢 3 到 5 倍。檔案大或用 Firefox 的人，桌面版 Chrome 是最快的路。
為什麼 AVIF 的處理比 WebP 慢？
AVIF 建立在 現代格式 編解碼上，它套用的預測與熵編碼遠比 WebP 以 為基礎的演算法複雜。現代格式 為了把壓縮推到極致而設計，代價是處理上的複雜，以慢換取頂尖輸出。在所有現代瀏覽器裡，AVIF 的解碼都很快，因為硬體解碼已是標配。但寫出 AVIF 是重活，一張大照片的運算確實吃資源，這就是為什麼它不會瞬間完成。
什麼時候該把 WebP 轉成 AVIF？
當你從頭到尾掌控投遞環境、受眾又用現代瀏覽器時，把照片與照片類內容從 WebP 升級到 AVIF 很值得，那 20 到 30 個百分點的縮減會換成更快的 LCP 分數。對 WebP 本來就很小巧的小圖示或簡單圖形、會被處理時間卡住流程的高流量頁面，或目的端指定要 WebP 的情況，就比較沒那麼划算。
詳細資訊
團隊關於工藝、格式以及一個好結果背後小決定的筆記。
為什麼 AVIF 在照片上贏過 WebP
AVIF 對 WebP 的壓縮優勢來自底層的編解碼。WebP 用的是 影格內引擎，本為影片而設計，自 2010 年起被拿來處理靜態圖。AVIF 背後的 現代格式 在 2018 年問世，此前多年的研究正是瞄準 與 的極限。現代格式 套用更積極的色度次取樣、細到 4 乘 4 像素的區塊切分，以及更有效的熵編碼器。實際結果，經多組大型照片測試集的 分析驗證，是 AVIF 在照片上的感知品質相同時，通常比 WebP 小 20 到 30 個百分點。在平塗色與硬邊的電腦繪圖上差距收窄，因為 WebP 較簡單的演算法處理那些圖樣很有效率。任何最重資產是照片的頁面，AVIF 升級都會帶來可量測的頻寬效益。
第二次有損處理的實務
當你把 WebP 轉成 AVIF，來源與輸出都是有損的。WebP 在當初被建立時，就已決定要捨棄哪些色彩資訊，而那些決定是無法復原的：轉成 AVIF 一點也找不回。接著 AVIF 處理會在拿到的像素資料上，以品質 85 做出自己的取捨。對照片來說，兩道有損處理疊起來，在一般顯示尺寸下仍接近無損，真實照片內容量到。對已被 WebP 處理弄差的圖形，第二道可能讓可見瑕疵雪上加霜。實務原則是：如果來源 WebP 在你打算顯示的尺寸下看起來乾淨，AVIF 也會乾淨。如果 WebP 已經帶著壓縮雜訊，出貨前先仔細看一遍 AVIF。
alpha 通道如何穿過去
WebP 與 AVIF 都把透明度以獨立的 alpha 平面存在色彩資料旁。轉換會讀取 WebP 的 alpha 通道，以全透明的方式合成，再交給 AVIF 處理，由它用 現代格式 影格內編碼以品質 85 寫出自己的 alpha 軌。柔和的透明漸層、羽化邊緣，以及半透明區域，都能挺過這趟來回。AVIF 的 alpha 平面在品質 85 下本身也是有損的，在極度放大時硬邊可能出現幾乎察覺不到的鑲邊。在網頁一般觀看尺寸下，與來源的差別並不可見。若要在小圖示上做像素級精準、alpha 邊必須準確的工作，請保留 WebP 來源，並在全縮放下檢查輸出再出貨。
跨瀏覽器與裝置的處理時間預期
AVIF 處理在每個瀏覽器工作階段暖機一次，第一次轉換會多花約一秒。之後 Chromium 的吞吐最佳：12 萬像素的縮圖約 40 毫秒，100 萬像素的照片 250 毫秒，4K 照片 2.8 秒，而觀察到的最差情況是整張 4,800 萬像素要 25 秒。Firefox 是明顯的例外，跑同一套處理約慢四倍，使 4K 情況接近 31 秒，大檔案則超過兩分鐘。WebKit 落在兩者之間，較靠近 Chromium。行動硬體在所有引擎上都比桌面慢 3 到 5 倍。日常逐檔轉換，筆電或桌機上的 Chrome 是實用之選。對用 Firefox 又有大圖的人，老實的建議是換瀏覽器，或留在 WebP。
核心網頁指標與 AVIF 升級
投放照片的頁面，每載入一張圖都付出頻寬成本。如果那些圖目前是 WebP，把它們轉成 AVIF，照片上每張傳輸大約省下 20 到 30 個百分點。一個頁面上 的 WebP 主視覺，轉成 AVIF 約落在 noticeably smaller。一個放著十二張 WebP 縮圖的產品格，AVIF 約省下整頁 noticeably smaller 的重量。當 LCP 元素是圖片時，這些省下會直接影響最大內容繪製。在 AVIF 全球瀏覽器支援約 94 個百分點之下，一個 picture 元素先給 AVIF、後接 WebP 退路，幾乎涵蓋所有流量。標記的成本每個圖片元件只付一次，而頻寬上的省下，會在之後每一次頁面載入重複回收。
為什麼 AVIF 轉換要靠伺服器
AVIF 建立在 現代格式 編碼之上，和現代影片同屬一個家族，為了換得緊湊的檔案，它被刻意做得很重。把這件事做好，尤其是大照片，在真正的伺服器上比在手機瀏覽器裡快得多也穩得多，所以這一對會把圖片送到我們的伺服器，去生成盡可能好的 AVIF。檔案被處理，結果回到你手上，下載會在大約 2 小時內移除，沒有帳號，也不長期保存。一次轉換多張圖片一律在伺服器上進行，它會把做好的一組拼成一個下載，並在同樣短的時間裡刪除。如果連不上我們的伺服器，單張轉換會改在瀏覽器裡生成，那個檔案留在本機，為了方便接受較慢的生成。交換很清楚：伺服器在最需要的格式上買來品質與速度，而你的檔案絕不會被保留得超過轉換所需的短暫視窗。