# HEIC to AVIF

> 兩邊容器都是 ISO-BMFF，但這是完整的解碼再重新編碼，不是換殼：實測 718,114 位元組的 HEIC 變成 491,861 位元組的 AVIF，全程在瀏覽器裡完成。

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

## What it does

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

這兩個檔案看起來像親戚，某種意義上也真的是：開頭都有一個 `ftyp` 盒子，都是 ISO-BMFF，這個轉檔器分辨它們靠的也是同一支函式，去讀相容品牌清單而不是信副檔名。這種相似會讓人以為轉檔只是換包裝 —— 把編過的畫面從一個殼裡搬到另一個殼裡，什麼都不會少。不是這樣，而且辦不到。來源殼裡的編碼資料是 HEVC，目標殼裡的是 AV1，再怎麼改寫盒子也不會讓其中一個變成另一個。畫面會由內建的 libheif 一路解到像素，再從頭編一次，所以重新編碼的每一項代價都原封不動地跟著來。

而且容器裡通常不只裝一張圖，能上路的只有其中一張。解碼器會把它找到的每一張都交出來（下面實測用的樣本裡就有兩張），轉檔器取第一張，並且把這件事告訴你。連拍的張數、影像序列、縮圖、深度等輔助影像都留在原檔裡。Apple 的 Live Photo 更進一步：動態是裝置上的另一個檔案，這個頁面根本收不到它，所以你下載到的是靜態畫面，手機裡那一組維持原樣。

最後掉的是精度，而且它在編碼器登場之前就掉了。libheif 交回來的是 8 位元 RGBA 的緩衝區，所以一張用 10 位元階調和 HDR 轉換曲線拍下的照片，送到 AV1 編碼器手上時已經被壓成 8 位元 —— 目標格式明明裝得下原本的深度，卻一次也沒被拿出來用。內嵌的 ICC 色彩描述檔不會複製，EXIF 也不會，所以拍攝時間、鏡頭、曝光和 GPS 都不會出現在結果裡。

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

2026-09-12，腳本解開釘住 commit 的 libheif 範例 —— 1280 × 854、兩張影像、718,114 位元組 —— 再把第一張以品質 85、速度 8 編碼：491,861 位元組，大約少 32%。這和同一個編碼器面對已經壓過的 JPG 或 WebP 時方向剛好相反，原因值得知道：這裡編碼器拿到的是解碼後的原圖，不是別的編碼器處理過的畫面，所以它不必替別人的壓縮痕跡花位元。還有一個旁證說明這筆實測是真的：這個數字和 PNG 那一列一模一樣，因為那一列的 PNG 只是同一批像素的無損來回。一張 1200 萬像素的手機照片，編碼時間會比這個樣本長上不少。

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

對方打得開 HEIC 就別轉。Apple 自家的 app 和近年的手機都原生吃得下，轉了什麼也沒賺到。需要 EXIF 的時候也一樣：日期、地點、鏡頭資料在結果裡全都不見，要當證據或帶著來源紀錄的照片不該被剝乾淨。想留著能播的 Live Photo、容器裡有之後可能會用到的連拍或深度圖、這是你唯一一份還要調亮部的母檔 —— 這幾種都留著。如果目標是舊的作業系統、印刷廠，或是收件清單早於 AV1 的表單，就選 JPG：檔案比較大，但到哪裡都通。要把 iPhone 照片放到自己管理的頁面上，這裡就是對的去處。

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

## Limits

這兩個檔案看起來像親戚，某種意義上也真的是：開頭都有一個 `ftyp` 盒子，都是 ISO-BMFF，這個轉檔器分辨它們靠的也是同一支函式，去讀相容品牌清單而不是信副檔名。這種相似會讓人以為轉檔只是換包裝 —— 把編過的畫面從一個殼裡搬到另一個殼裡，什麼都不會少。不是這樣，而且辦不到。來源殼裡的編碼資料是 HEVC，目標殼裡的是 AV1，再怎麼改寫盒子也不會讓其中一個變成另一個。畫面會由內建的 libheif 一路解到像素，再從頭編一次，所以重新編碼的每一項代價都原封不動地跟著來。

而且容器裡通常不只裝一張圖，能上路的只有其中一張。解碼器會把它找到的每一張都交出來（下面實測用的樣本裡就有兩張），轉檔器取第一張，並且把這件事告訴你。連拍的張數、影像序列、縮圖、深度等輔助影像都留在原檔裡。Apple 的 Live Photo 更進一步：動態是裝置上的另一個檔案，這個頁面根本收不到它，所以你下載到的是靜態畫面，手機裡那一組維持原樣。

最後掉的是精度，而且它在編碼器登場之前就掉了。libheif 交回來的是 8 位元 RGBA 的緩衝區，所以一張用 10 位元階調和 HDR 轉換曲線拍下的照片，送到 AV1 編碼器手上時已經被壓成 8 位元 —— 目標格式明明裝得下原本的深度，卻一次也沒被拿出來用。內嵌的 ICC 色彩描述檔不會複製，EXIF 也不會，所以拍攝時間、鏡頭、曝光和 GPS 都不會出現在結果裡。

## FAQ

### 這個轉換只是換一個容器嗎？

不是。兩種格式共用 ISO-BMFF 這個外殼，裡面的編碼卻分別是 HEVC 和 AV1，所以畫面要解到像素再重編一次。那代表多了一道有損工序，元資料和其他影像沒辦法直接跟過去的原因也在這裡。

### 多影像的容器裡，最後輸出的是哪一張？

解碼器交出來的第一張，轉完之後畫面上會寫明這件事。連拍、序列、縮圖和深度圖之類的輔助影像都留在原檔裡。如果你要的是另一張，請在轉檔之前把它取出來，不要等轉完才想辦法。

### 10 位元階調和 HDR 留得住嗎？

留不住。解碼器交回來的是 8 位元 RGBA，所以深度在編碼器被呼叫之前就沒了 —— 即使目標格式本身完全存得下。在手機上看起來連續的高光收尾，轉完之後可能會出現一圈一圈的色帶。

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

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

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

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

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

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

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

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