# PNG to AVIF

> 在瀏覽器裡把 PNG 以品質 85、速度 8 編成 AVIF，檔案不離開裝置。alpha 色版原封不動，16 位元與動畫則留不住；實測 1,689,485 變成 491,861 位元組。

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

## What it does

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

透明度在這裡是安全的，這點值得先講，因為它正是選 AVIF 而不選 JPG 的理由：alpha 色版直接接過去，不會鋪上任何背景色，也不會跳出壓平的警告。動畫則相反。這個工具只對兩種目標格式寫得出動畫，GIF 和 WebP，而 AVIF 兩個都不是。所以多影格的 PNG 會被打開、被認出是動畫，然後在只留下第一個影格之後關掉，並附上一則警告。顯示間隔和循環次數沒有地方可去。格式本身裝得下動畫，是這條路徑給不了它。

位元深度撞到的那道天花板，是流程的限制而不是格式的限制。AVIF 規格寫得下 10 位元、12 位元的取樣和 HDR 轉換函式，但這裡交給編碼器的，是從 8 位元 RGBA canvas 讀回來的 `ImageData`。一份 48 位元的 PNG 母檔，在編碼器看到它之前就已經被量化成每通道 8 位元，AVIF 那些多出來的餘裕從頭到尾空著。像素以外的東西也一樣：整個流程是解碼後重做，不是換個殼，所以 ICC 色彩描述檔、`gAMA` 與 `cHRM`、文字區塊和 EXIF 都不會出現在輸出裡。標了 Display P3 的檔案會變成沒有標記的數值，看的人一律當成 sRGB 讀。

最後一項損失是你自己選的。這條路徑是有損的，而且沒有第二個選項：設定裡那個無損的勾選框屬於 WebP 編碼器，所以就算原檔像素完全精確，出來的也是品質 85 的近似值。通常是很好的近似 —— AV1 的框內預測處理平面和柔順漸層比 DCT 系的格式強得多 —— 但它不可逆，而且來回轉幾次就會疊起來。

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

2026-09-12 那一輪從 1,689,485 位元組的 1280 × 854 PNG 開始，它已經把「最佳化 (oxipng)」打開寫過。這個工具預設把那個選項關著。交給 @jsquash/avif 以品質 85、速度 8 編碼後是 491,861 位元組，大約少了 71%。速度 8 不是偷工。沒有 COOP/COEP 標頭就沒有 `SharedArrayBuffer`，編碼器永遠是單執行緒；在一張 1200 萬像素的照片上實測，速度 8 比速度 6 快三到五倍，大小差距不到百分之一 —— 這是「幾秒鐘」和「久到想關分頁」的差別。平面插畫本來就壓得不錯，差距會縮小；雜訊多的照片則相反。

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

動畫而且動得重要，就留著 PNG，或改選 WebP，它每個影格都留得住。16 位元的高度圖、深度圖、科學用影像也留著 —— 毀掉資料的是 8 位元 canvas 那一步，不是編碼器。任何必須維持像素精確的東西也一樣：favicon 和 app 圖示流程、建置工具依座標切的雪碧圖、拿來當測試基準的畫面截圖。郵件環境相容度仍然參差，印刷和製版通常直接退件。另外，在手機上一次跑一大批也要想一下，每個檔案都是實打實的 CPU 工作。至於要放在自己管理的頁面上的照片或插畫，這是整個站上單筆最大的縮減。

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

## Limits

透明度在這裡是安全的，這點值得先講，因為它正是選 AVIF 而不選 JPG 的理由：alpha 色版直接接過去，不會鋪上任何背景色，也不會跳出壓平的警告。動畫則相反。這個工具只對兩種目標格式寫得出動畫，GIF 和 WebP，而 AVIF 兩個都不是。所以多影格的 PNG 會被打開、被認出是動畫，然後在只留下第一個影格之後關掉，並附上一則警告。顯示間隔和循環次數沒有地方可去。格式本身裝得下動畫，是這條路徑給不了它。

位元深度撞到的那道天花板，是流程的限制而不是格式的限制。AVIF 規格寫得下 10 位元、12 位元的取樣和 HDR 轉換函式，但這裡交給編碼器的，是從 8 位元 RGBA canvas 讀回來的 `ImageData`。一份 48 位元的 PNG 母檔，在編碼器看到它之前就已經被量化成每通道 8 位元，AVIF 那些多出來的餘裕從頭到尾空著。像素以外的東西也一樣：整個流程是解碼後重做，不是換個殼，所以 ICC 色彩描述檔、`gAMA` 與 `cHRM`、文字區塊和 EXIF 都不會出現在輸出裡。標了 Display P3 的檔案會變成沒有標記的數值，看的人一律當成 sRGB 讀。

最後一項損失是你自己選的。這條路徑是有損的，而且沒有第二個選項：設定裡那個無損的勾選框屬於 WebP 編碼器，所以就算原檔像素完全精確，出來的也是品質 85 的近似值。通常是很好的近似 —— AV1 的框內預測處理平面和柔順漸層比 DCT 系的格式強得多 —— 但它不可逆，而且來回轉幾次就會疊起來。

## FAQ

### 動畫 PNG 轉成 AVIF 之後還會動嗎？

不會。只有第一個影格會被轉換，而且會跳警告，因為工具只對 GIF 和 WebP 寫得出動畫。動畫一定要留就選 WebP：它會保住每個影格和原本的顯示間隔，而且通常還比原檔小。

### PNG 的 16 位元精度送得進 AVIF 嗎？

送不進去。編碼前畫面要先畫到 8 位元 RGBA 的 canvas 上，更深的取樣在那一步就被量化掉了。格式本身裝得下 10 或 12 位元，但這條流程能給的只有 8 位元，結果也救不回原來的精度。

### 為什麼只有轉 AVIF 特別慢？

因為輸出是一張 AV1 靜態影格，而 AV1 編碼真的很吃算力，PNG 壓縮則幾乎免費。加上多執行緒需要 SharedArrayBuffer，而本站沒有設它所需要的標頭，所以編碼器是單執行緒跑的。速度 8 就是把等待壓在可忍受範圍裡的那個設定。

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

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

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

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

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

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

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

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