# WebP to AVIF

> 在瀏覽器裡把 WebP 轉成 AVIF，檔案不離開裝置。動畫只剩第一個影格，無損會變成有損，10 位元也送不進去，而實測 319,834 位元組還漲到 485,143。

- URL: https://bytescope.dev/zh-Hant/image-convert/webp-to-avif/
- Locale: zh-Hant · Also: [en](https://bytescope.dev/en/image-convert/webp-to-avif.md) · [ja](https://bytescope.dev/ja/image-convert/webp-to-avif.md)
- Runs: 檔案不會離開你的瀏覽器 — 全部在本機處理。
- Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile.
- Updated: 2026-09-08

## What it does

### WebP 轉成 AVIF 會失去什麼

先倒下的是動畫，而且在本站所有以 WebP 為來源的路線裡，只有這一條留不住影格。能寫出動畫的目標只有 GIF 和 WebP 兩個，其他一律走靜態路徑，所以多影格的來源會被打開、被認出來，然後在留下第一個影格之後關掉，並附上一則警告。後面每個影格、每個影格自己的顯示間隔，以及循環次數，一起被丟掉。如果你是為了把動畫變小才來的，重新編回 WebP 本身可以保住動作，選 GIF 也可以，只是位元組要付得多得多。

第二項損失會打中拿這個格式做介面素材的人。用無損模式寫出來的 WebP 是像素精確的，而這條轉換路徑沒辦法把那個承諾帶過去：設定裡的無損勾選框是給 WebP 編碼器用的，這一側永遠依滑桿上的品質做有損輸出。平面插畫、圖示、畫面截圖、圖解 —— 正好就是無損 WebP 存在的理由 —— 會變成近似值回來，本來銳利的一像素邊界換成一圈糊掉的暈。至少 alpha 色版沒事：不會鋪背景，半透明的像素也還是半透明。

剩下的就是把檔案從像素重做的代價。來源 RIFF 容器裡的 `EXIF` 與 `ICCP` 區塊不會轉過去，所以拍攝資訊和色彩定義都沒了，結果會被當成 sRGB 讀。解碼後的緩衝區是 8 位元，所以能用到 10 位元、12 位元那套能力的東西一樣也沒送到。再加上兩邊都是有損，這是第二代：新的編碼器沒有辦法把第一代的抹平和真正的細節分開，只好一併留下。

### 實測時檔案大小怎麼變

2026-09-12，腳本量了一張 1280 × 854、品質 85 的有損 WebP，319,834 位元組，再以品質 85、速度 8 重編成 AVIF：485,143 位元組，大了大約 52%。大家常引用的 15–25% 優勢，是兩個編碼器從同一份沒壓過的母檔出發、對齊視覺品質、在測試圖集上比出來的。這裡的情況是：第二個編碼器拿到的是另一套刻度上的同一個數字（libaom 的 85 瞄得比 libwebp 的高），而且手上那張圖已經量化過一次，它自然要花位元去重現。把品質滑桿往下拉、盯著大小數字看。滑桿上的數字跨格式並不是共用單位。

### 什麼時候不該把 WebP 轉成 AVIF

想繼續動的動畫不要轉，想維持精確的無損素材也不要轉 —— 這條路徑破壞的就是這兩個承諾。整批重轉也先放下：同樣的滑桿位置很可能是在花位元組而不是省，而且每個檔案都多一代有損。小素材更是完全不必，圖示和縮圖幾乎都是容器的量，編碼器根本沒有發揮空間。值得做的是一張大的照片，而且你有餘裕把品質調低再比對結果；也值得從原始母檔轉，而不是從已經編過一次的發布用副本轉。

轉換完全在你的瀏覽器內進行 — 不上傳、不排隊、無浮水印。想放幾個檔案都行，可逐一下載，也能打包成 zip。

## Limits

先倒下的是動畫，而且在本站所有以 WebP 為來源的路線裡，只有這一條留不住影格。能寫出動畫的目標只有 GIF 和 WebP 兩個，其他一律走靜態路徑，所以多影格的來源會被打開、被認出來，然後在留下第一個影格之後關掉，並附上一則警告。後面每個影格、每個影格自己的顯示間隔，以及循環次數，一起被丟掉。如果你是為了把動畫變小才來的，重新編回 WebP 本身可以保住動作，選 GIF 也可以，只是位元組要付得多得多。

第二項損失會打中拿這個格式做介面素材的人。用無損模式寫出來的 WebP 是像素精確的，而這條轉換路徑沒辦法把那個承諾帶過去：設定裡的無損勾選框是給 WebP 編碼器用的，這一側永遠依滑桿上的品質做有損輸出。平面插畫、圖示、畫面截圖、圖解 —— 正好就是無損 WebP 存在的理由 —— 會變成近似值回來，本來銳利的一像素邊界換成一圈糊掉的暈。至少 alpha 色版沒事：不會鋪背景，半透明的像素也還是半透明。

剩下的就是把檔案從像素重做的代價。來源 RIFF 容器裡的 `EXIF` 與 `ICCP` 區塊不會轉過去，所以拍攝資訊和色彩定義都沒了，結果會被當成 sRGB 讀。解碼後的緩衝區是 8 位元，所以能用到 10 位元、12 位元那套能力的東西一樣也沒送到。再加上兩邊都是有損，這是第二代：新的編碼器沒有辦法把第一代的抹平和真正的細節分開，只好一併留下。

## FAQ

### 動畫 WebP 轉完之後還會動嗎？

不會。只留下第一個影格，而且會跳警告。能寫出動畫的是 GIF 和 WebP 自己，所以動作重要的話就重新編回 WebP，每個影格和顯示間隔都會留著；選 GIF 也留得住，但檔案會大很多。

### 無損的 WebP 走這條路會怎樣？

會變成有損的。設定裡的無損屬於 WebP 編碼器，這一側沒有對應的選項，所以像素精確的素材會依滑桿上的品質被近似掉。對圖示和平面插畫來說，這是值得避開的降級。

### 品質設定一樣，為什麼輸出反而比較大？

因為那個設定不是共用單位。兩個編碼器各自把 85 對應到自己的量化器，新的那個瞄得比較高，於是它把一張已經壓過一次的圖複製得更忠實、也更大。實測是 319,834 位元組變成 485,143。

### 我的圖片會被上傳到任何地方嗎？

不會。轉換在你的瀏覽器內使用 canvas API 和 Web Worker 完成 — 檔案不會離開你的裝置。沒有上傳步驟、不用排隊，檔案大小也只受限於你電腦的記憶體。

### 轉換後的圖片會保留 EXIF 中繼資料嗎？

不會 — 而這正是特色之一。透過 canvas 重新編碼會移除所有中繼資料：GPS 位置、相機型號、時間戳記和色彩描述檔。輸出只包含像素，而這通常正是你公開分享圖片前想要的結果。

### 可以一次轉換很多張圖片嗎？

可以。拖放或貼上任意數量的檔案；每個檔案都會在背景轉換，各自有進度顯示和下載按鈕，也可以把全部內容打包成 .zip 一次下載。

### 轉檔會讓畫質變差嗎？

看你選的目標格式。不管來源和目標是哪兩種格式，轉換器一律先解碼成原始像素再重新編碼，中繼資料也是這樣被移除的。目標是無損格式（PNG，以及在 256 色限制內的 GIF）時，像素和解碼出來的完全一樣；目標是 JPEG、WebP 或 AVIF 時，則由品質滑桿控制取捨，而且來源本來就是有損檔的話，會再多疊一層損失。