# AVIF to PNG

> 就算瀏覽器顯示不出 AVIF，也能在本機轉成 PNG 打開，透明度完整留著。10 位元階調會被壓成 8 位元，實測 491,861 位元組變成 1,823,978。

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

## What it does

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

一個無損的目標格式竟然會掉位元深度，是這裡最沒人預期、卻影響最大的一項。來源格式規格裡寫得下 10 位元、12 位元的取樣和 HDR 轉換函式，但這個轉換不管走哪一條解碼路徑，最後都停在 8 位元的緩衝區：瀏覽器自己的解碼器畫進 8 位元的 canvas，內建的 WASM 備援則回傳 8 位元的 `ImageData`。所以輸出只對那八個位元無損，再往上就什麼都不保證：一段在 10 位元來源裡完全平滑的漸層，可能在一個大三四倍的檔案裡看得見一階一階。如果畫面本身是 HDR 調光，那個動態範圍不是被壓縮 —— 是在編碼開始前就沒了。

動畫停在第一個影格。多影格的來源會被偵測到，其餘影格和時間資訊被丟掉，並且警告你只轉了一個影格，因為這條路徑寫出來的是單張影像檔而不是 APNG。解碼本身還有兩個細節值得知道。流程會先問瀏覽器；瀏覽器完全解不開時，才載入 WASM 的 AV1 解碼器，並用一則注記告訴你備援啟動了 —— 也就是說，連顯示不出來的環境都轉得動。走備援那條路時，轉檔器會自己從容器裡讀出 `irot` 和 `imir` 這兩個方向屬性再套上去，因為 WASM 解碼器交回來的畫面是沒有轉過的。

alpha 色版完整留著，任何地方都不會被鋪上背景色，而且從這裡開始不會再掉畫質。最後這句話的說法很重要：無損講的是「從現在起」，不是「到目前為止」。原本編碼器抹掉的東西、它在高反差邊緣留下的光暈，還有它合成出來的底片顆粒，現在都已經是畫面本身，會被一模一樣地、永久地記錄下來。

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

2026-09-12，腳本量了一張 1280 × 854、品質 85 的來源，491,861 位元組，解碼後把「最佳化 (oxipng)」打開寫成 PNG：1,823,978 位元組，大約 3.7 倍。把這個倍率推高的有兩件事：無損地保存一張照片本來就貴，而且壓縮器現在還得把前一個編碼器的抹平和鬼影當成細節記下來，那些東西和真正的紋理一樣難預測。另外要注意，實測是把「最佳化 (oxipng)」打開量的，而上面那個勾選框預設是關的 —— 維持關閉的話，瀏覽器自家編碼器產出的結果通常還會再大一點。平面插畫和畫面截圖膨脹得少很多，因為列篩選和調色盤化有東西可以發揮。

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

不要為了發布而轉。來源本來就是小的那個，這條路只把位元組乘上去而沒有增加任何東西；真的有客戶端讀不懂，一個 JPG 備援的成本也只有它的零頭。也不要拿來典藏：結果並沒有比來源更忠於現場，只是比較大，而且已經失去了典藏該拿來建索引的元資料。更不要指望它能救回細節、銳利度或動態範圍。除非你有每張數十 MB 的空間，否則也別對一整個資料夾的 1200 萬像素照片下手。它真正對的時機是：桌面編輯器、辦公室軟體、印刷流程或上傳表單直接拒收來源檔、這個交接過程中透明度必須活下來，或是你需要一份可以反覆編輯重存而不再掉畫質的中繼檔。

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

## Limits

一個無損的目標格式竟然會掉位元深度，是這裡最沒人預期、卻影響最大的一項。來源格式規格裡寫得下 10 位元、12 位元的取樣和 HDR 轉換函式，但這個轉換不管走哪一條解碼路徑，最後都停在 8 位元的緩衝區：瀏覽器自己的解碼器畫進 8 位元的 canvas，內建的 WASM 備援則回傳 8 位元的 `ImageData`。所以輸出只對那八個位元無損，再往上就什麼都不保證：一段在 10 位元來源裡完全平滑的漸層，可能在一個大三四倍的檔案裡看得見一階一階。如果畫面本身是 HDR 調光，那個動態範圍不是被壓縮 —— 是在編碼開始前就沒了。

動畫停在第一個影格。多影格的來源會被偵測到，其餘影格和時間資訊被丟掉，並且警告你只轉了一個影格，因為這條路徑寫出來的是單張影像檔而不是 APNG。解碼本身還有兩個細節值得知道。流程會先問瀏覽器；瀏覽器完全解不開時，才載入 WASM 的 AV1 解碼器，並用一則注記告訴你備援啟動了 —— 也就是說，連顯示不出來的環境都轉得動。走備援那條路時，轉檔器會自己從容器裡讀出 `irot` 和 `imir` 這兩個方向屬性再套上去，因為 WASM 解碼器交回來的畫面是沒有轉過的。

alpha 色版完整留著，任何地方都不會被鋪上背景色，而且從這裡開始不會再掉畫質。最後這句話的說法很重要：無損講的是「從現在起」，不是「到目前為止」。原本編碼器抹掉的東西、它在高反差邊緣留下的光暈，還有它合成出來的底片顆粒，現在都已經是畫面本身，會被一模一樣地、永久地記錄下來。

## FAQ

### 轉完之後平滑的漸層為什麼出現色帶？

因為來源可能用 10 或 12 位元存每個通道，而這條解碼路徑只到 8 位元。讓漸層看起來連續的那些中間階，在編碼之前就被量化掉了。無損格式能保存的只有交到它手上的數值，不包括它從沒見過的那些。

### 瀏覽器根本顯示不出來的檔案也轉得了嗎？

轉得了。流程先試瀏覽器自己的解碼器，被拒絕之後由內建的 WASM AV1 解碼器接手，並用一則注記告訴你。走那條路時會從容器裡讀出方向屬性再手動套上，所以結果一樣是正的。

### 換成無損格式畫面會不會變好？

不會。它的意思是從這裡開始不再掉東西。原本編碼器留下的抹平、邊緣光暈和合成顆粒都會被原樣記下來，所以你拿到的是一份忠實（而且大很多）的近似複本，不是原始場景的還原。

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

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

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

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

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

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

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

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