# AVIF to WebP

> 在瀏覽器裡把 AVIF 轉成 WebP，檔案不離開裝置：動畫的每個影格都留得住，alpha 色版原封不動，HDR 則會被壓平，而實測 491,861 位元組變成 312,694。

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

## What it does

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

先講不會失去的，因為那正是選這個目標的理由：動畫。這個轉檔器寫得出動畫的格式有兩個，WebP 是其中之一。只要瀏覽器的 `ImageDecoder` 回報不只一個影格，工具就會逐格解碼、重新編碼，再組成一張帶著原本顯示間隔和循環設定的動畫 WebP，想要更小還可以設每秒影格數上限。只有在組裝過程丟出錯誤時才會退回單張靜態圖，而且它會用警告講出來，不是默默把動作吃掉。有一點得誠實說：瀏覽器若沒有 WebCodecs 的 `ImageDecoder`，動畫偵測根本不會啟動，你拿到的就是第一個影格 —— 轉完後的警告會告訴你拿到的是哪一種。alpha 色版一樣安全，不會鋪上背景。

真正會掉的是深度和範圍。來源格式規格裡有 10 位元、12 位元的取樣和 HDR 轉換函式，目標格式兩樣都沒有；何況像素到編碼器手上時，本來就已經是從 canvas 讀回來的 8 位元緩衝區。HDR 調光在編碼前就被壓回標準範圍，10 位元的漸層一旦降到每通道 256 階也可能出現色帶。內嵌的 ICC 色彩描述檔和元資料同樣不會轉過去，所以輸出沒有標記，會被當成 sRGB 讀。

剩下的是第二道有損的一般代價。預設兩邊都是有損，新的編碼器沒辦法把前一個的抹平和真正的紋理分開，於是先重現它、再在上面量化一次。設定裡的無損勾選框對這個目標是有效的，會把解碼後的像素原樣保留 —— 但它也會把既有的壓縮痕跡一起原樣保留，而且檔案大很多，用在照片上幾乎不會是任何人要的結果。

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

2026-09-12，腳本量了一張 1280 × 854、品質 85、速度 8 的來源，491,861 位元組，再以品質 85 重編成有損 WebP：312,694 位元組，大約少 36%。這一段請讀仔細，因為它和兩個編碼器的名聲所預期的正好相反，但它並沒有推翻那個名聲。兩邊都被設成 85，而那兩個刻度不是共用單位，第二個瞄得比第一個低，所以它做出一個比較小、也比較不忠實的檔案。從沒壓過的母檔、對齊視覺品質來比，新的編碼器贏得很輕鬆。這個數字真正證明的只有一件事：判斷這個轉換要看結果和大小數字，不要看滑桿位置。

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

後面真的沒有東西拒收來源檔就別轉，現在的瀏覽器都讀得懂，你只是白付一代有損。打算當母檔留著的 HDR 或 10 位元影像也別轉，範圍在路上就被壓平了。也不要憑一筆實測就整批重轉：每過一次就少掉一點細節，小素材本來又幾乎都是容器的量。值得做的理由都很具體：處理不了來源檔的 CDN 或圖片流程、要照顧的舊版 Safari、靠副檔名擋人的平台或上傳表單，還有最強的那一個 —— 你需要把一段動畫換成更多工具吃得下的格式，這件事這條路徑做得比本站任何其他目標都好。

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

## Limits

先講不會失去的，因為那正是選這個目標的理由：動畫。這個轉檔器寫得出動畫的格式有兩個，WebP 是其中之一。只要瀏覽器的 `ImageDecoder` 回報不只一個影格，工具就會逐格解碼、重新編碼，再組成一張帶著原本顯示間隔和循環設定的動畫 WebP，想要更小還可以設每秒影格數上限。只有在組裝過程丟出錯誤時才會退回單張靜態圖，而且它會用警告講出來，不是默默把動作吃掉。有一點得誠實說：瀏覽器若沒有 WebCodecs 的 `ImageDecoder`，動畫偵測根本不會啟動，你拿到的就是第一個影格 —— 轉完後的警告會告訴你拿到的是哪一種。alpha 色版一樣安全，不會鋪上背景。

真正會掉的是深度和範圍。來源格式規格裡有 10 位元、12 位元的取樣和 HDR 轉換函式，目標格式兩樣都沒有；何況像素到編碼器手上時，本來就已經是從 canvas 讀回來的 8 位元緩衝區。HDR 調光在編碼前就被壓回標準範圍，10 位元的漸層一旦降到每通道 256 階也可能出現色帶。內嵌的 ICC 色彩描述檔和元資料同樣不會轉過去，所以輸出沒有標記，會被當成 sRGB 讀。

剩下的是第二道有損的一般代價。預設兩邊都是有損，新的編碼器沒辦法把前一個的抹平和真正的紋理分開，於是先重現它、再在上面量化一次。設定裡的無損勾選框對這個目標是有效的，會把解碼後的像素原樣保留 —— 但它也會把既有的壓縮痕跡一起原樣保留，而且檔案大很多，用在照片上幾乎不會是任何人要的結果。

## FAQ

### 動畫 AVIF 的影格在 WebP 裡留得住嗎？

在提供 WebCodecs `ImageDecoder` 的瀏覽器裡留得住：每個影格都會重新編碼再組回去，顯示間隔和循環設定照原本的走，想更小還能設每秒影格數上限。沒有那個 API 的環境偵測不到動畫，你會拿到第一個影格，警告會講清楚。

### 輸出是真的變小，還是只是畫質降低？

主要是畫質。實測是 491,861 位元組變成 312,694，但兩個編碼器都跑在對不起來的 85 上，而第二個瞄得比較低。請用畫面和大小數字去比，不要假設滑桿在兩邊是同一個意思。

### 輸出裝得下來源的 HDR 或 10 位元階調嗎？

裝不下。目標格式沒有 HDR，深度也只到 8 位元，何況像素送到編碼器時本來就是 8 位元的緩衝區。HDR 調光在路上被壓回標準範圍，平滑的 10 位元漸層降到每通道 256 階之後也可能出現色帶。

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

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

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

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

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

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

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

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