PNG 轉 AVIF,透明度一點都不丟

交出一張 PNG,拿回一張小巧的 AVIF,透明區域在整段轉換裡全程存活。

或將圖片拖放至此

關於此工具

把 PNG 變成 AVIF,連同透明度一起保留。你拖入檔案,頁面讀取你的 PNG,再把它寫回為 AVIF,也就是源自 AV1 編解碼的影像格式。AVIF 編碼很重,所以為了得到最乾淨的結果,Araluma在我們的伺服器上執行它,若那條路不通,工作會退回到在瀏覽器中執行的編碼器。編碼是品質 85 的有損格式,照片約 42.6 dB PSNR,與原圖足夠接近,眼睛很少察覺差異,通常比同一張圖存為 WebP 輕 30 到 50 個百分點。JPG 會丟掉透明度,而 AVIF 原樣保留完整的 Alpha 通道。每當一個檔案到達我們的伺服器,它就會被編碼,結果會在大約 2 小時內清除。這一組適合追求為現代頁面使用盡可能輕的透明素材的設計與前端開發。

把一張 PNG 轉成 AVIF

把一張 PNG 轉成 AVIF

把一張 PNG 拖進放置區,或輕點它去瀏覽選檔。沒有要去找的轉換按鈕,檔案一到工作就開始。一個工作階段的開頭那次轉換會花約一秒載入轉換程式。從那之後,一張小圖約 40 毫秒搞定,一張 1 百萬畫素的照片約 250 毫秒,一格 4K 約 2.8 秒。任何超過 8 百萬畫素的,在手機上可能拉長到 10 或 30 秒。AVIF 一出現,下載就會用原本的名字加上 .avif 副檔名把它寫出來,大小讀數會把新舊並列。

透明會不會存活

透明會不會存活

會,而那份存活正是這裡選 AVIF 而非 JPG 的整個重點。alpha 通道對 AVIF 是原生的,所以一個進去時透明的像素,出來時仍然透明。一枚漂浮在虛無上的徽章、一張羽化的去背產品圖、一個圓角圖示,每一個都帶著未動的遮罩落進 AVIF,背後沒有白色矩形,邊緣也沒有光暈。JPG 根本辦不到,它沒有 alpha,會在原本透明的地方塗上一塊純色。WebP 也能裝載 alpha,但在相同品質下追不上 AVIF 的大小。要把透明美術送進當前的瀏覽器,沒有別的東西這麼緊湊。

AVIF 到底輕了多少

AVIF 到底輕了多少

穩在品質 85,一張 AVIF 在照片上往往比 PNG 輕三到五成,比同一張圖的 WebP 輕兩到三成。一次開發量測把一張 4K 照片從存成 JPG 的 116 KB 降到 AVIF 的 16 KB。小圖也按同樣方式縮放,一張 17 KB 的 PNG 縮到約 6 KB。已經被壓扁的來源回吐得較少,平色圖形或硬邊標誌則可能幾乎不動。自然照片交出最大的削減,而那恰恰是把大多數產品頁與英雄區塞滿的那種檔案,省下的地方就在這裡。

畫質與耗時

畫質與耗時

身為一種有損格式,AVIF 在這裡以固定的品質 85 運作。照片在那個層級坐落在 42.6 dB PSNR 附近,對尋常場景而言讀起來與 PNG 無異。清晰文字與細線稿是例外,在任何有損設定下都可能沾上微弱瑕疵,那些東西屬於 PNG。耗時跟著圖片大小與引擎走。Chrome 桌面版約四分之一秒處理一個百萬畫素,約 2.8 秒處理八百萬畫素。Firefox 要花約四倍長,手機再加三到五倍。一個工作階段的第一次也帶著轉換程式啟動時的短暫暖機。

你的檔案在哪裡被處理

你的檔案在哪裡被處理

AVIF 生產起來很吃力,所以為了達到最佳品質與速度,Araluma在我們的伺服器上執行這次轉換,當伺服器搆不到時退回到瀏覽器中的編碼器。也就是說轉換時你的 PNG 可能會傳到我們這裡。處理很簡單。檔案變成 AVIF,結果回到你手中,兩者都會在大約 2 小時內從我們的伺服器清除。我們不保留你影像的副本,不要求帳號,也不會把它用於你發起的轉換之外。若伺服器路徑不可用,編碼會在你的瀏覽器中執行。無論哪條路,你都會得到相同的 AVIF,具有相同的 Alpha 通道與相同的品質。

AVIF 在 2026 年的落腳處

AVIF 在 2026 年的落腳處

2026 年的涵蓋率坐落在全球瀏覽器約 94.3 percent:Chrome 從 85 起、Firefox 從 93 起、Safari 從 16.4 起(iOS 16 以後),以及 Edge 從 121 起。死守不退的是 Internet Explorer、Opera Mini,以及任何仍停在 iOS 15 或更早的東西。若你有一塊訪客住在那裡,就以 AVIF 領頭,讓 picture 元素自動把他們降到 WebP。對多數現代流量,那個退回鮮少觸發,因為 Chrome 與 Safari 扛起行動造訪的大半,而且兩者自 2022 年起就原生繪製 AVIF。

運作方式

  1. 加入你的 PNG

    把一張 PNG 拖進放置區,或輕點它開啟檔案瀏覽器,從你的裝置挑一張。

  2. 讓它轉換

    開頭那次轉換花約一秒載入轉換程式。同分頁裡之後的每一次都更快。

  3. 對照大小

    AVIF 一就緒,讀數就把 PNG 大小擺在新的 AVIF 大小旁邊,讓削減一目了然。

  4. 儲存 AVIF

    按下載按鈕把完成的檔案寫到你的裝置,沿用原本的主檔名並換上嶄新的 .avif 副檔名。

繼續轉換

為了相容需要反過來轉,或想要 WebP 換更快的轉換與更廣的支援嗎?兩者都只差一下點按。

常見問題

為什麼要把 PNG 變成 AVIF

因為 AVIF 是當前瀏覽器會繪製的最輕格式,而且邊做邊把透明留住。前端開發者與設計師在透明的介面零件、去背產品圖,以及必須維持便宜下載的圖示上會伸手去拿它。大小的削減很具體,往往在視覺品質大致相同下落到 PNG 的三到五成以下,而那條 alpha 通道一路順帶過去毫髮無傷,換成 JPG 早就把它抹掉了。

透明會留住嗎

會。AVIF 帶有原生的 alpha 通道,這個組合把它直直送過去。PNG 裡的一塊透明區域,在 AVIF 裡仍是透明。JPG 應付不來,它沒有 alpha,會往那個缺口丟一塊純色,而 AVIF 像 PNG 那樣對待去背圖、標誌與堆疊的圖層,只是小上許多。你從來不必動手重畫遮罩。

哪些瀏覽器能顯示 AVIF

每一款當前的引擎都能。Chrome 從版本 85 起應付得來,Firefox 從 93、Safari 從 16.4 連同 iOS 16,Edge 從 121。應付不來的是 Internet Explorer、Opera Mini,以及被留在 iOS 15 的裝置。要搆到那條尾巴,就把圖片包進一個 HTML 的 picture 元素,先端出 AVIF,瀏覽器說不行時就降到 WebP 或 PNG。

這個 AVIF 是有損還是無損

AVIF 兩者都支援,但這裡的成品是品質 85 的有損。照片在那個層級讀起來約 42.6 dB PSNR,多數人沒辦法把它和來源分開。帶硬邊、細小字型,或大片平色色塊的影像,在任何品質下都可能露出輕微瑕疵。當每一個像素都得分毫不差時,就保留那張 PNG,別去轉它。

AVIF 或 WebP,差別在哪

在相近品質的照片上,AVIF 比 WebP 小約兩到三成。WebP 以更寬的觸及作答,包含較舊的 Safari,而 AVIF 在 2026 年蓋住約 94.3 percent 的瀏覽器。當頻寬是首要、受眾又現代時,AVIF 勝出。當你得搆到所有人時,把 WebP 留在手邊。2026 年常見的配置是先送 AVIF,後面用 picture 元素墊著 WebP。

轉換要跑多久

大小與引擎說了算。一個工作階段的開頭那次花約一秒備妥轉換程式。一旦暖了,一張小圖約 40 毫秒搞定,一張百萬畫素照片接近 250,一格 4K 在 Chrome 裡約 2.8 秒。超過 8 百萬畫素,手機可能坐上 10 到 30 秒。Firefox 以 Chrome 約四分之一的速度爬行,所以大工作在 Chrome 裡收尾得早些。

詳細資訊

團隊關於工藝、格式以及一個好的圓形裁剪背後小決定的筆記。

是什麼讓 AVIF 在大小上輾過 PNG
AVIF 騎在 AV1 技術上,調校的目標是眼睛接受什麼,而不是位元層級的完美保真。PNG 倚靠對原始像素套用的 DEFLATE,無損,卻對填滿照片內容的那些冗餘視而不見。AVIF 把那份冗餘換成影片編碼的區塊預測手法,丟掉視覺系統根本登錄不到的細節。回報很陡。那張 116 KB 的照片在品質 85 下變成約 16 KB,而一張透明的 PNG 通常比相配的 WebP 跌掉三到五成。高解析照片把差距拉寬,樸素圖形把它縮窄。任何把透明影像出貨給現代人群的網站,都會把那份節省化成更快的頁面與更輕的頻寬帳單。
在轉換裡一路追蹤 alpha 通道
PNG 與 AVIF 都把透明保存在緊鄰色彩的一條獨立 alpha 平面上。當這個組合讀你的 PNG 時,解碼器把色彩像素和遮罩拆開。接著轉換程式鋪下一條自己的全新 alpha 軌,倚靠 AV1 的內框編碼把色彩與遮罩一起在品質 85 下擠壓。透明從不熔進色彩,背後也從不被填上。投影、羽化的邊緣,以及半透明的漸層,全都如實過渡而來。AVIF 加進來的唯一代價,是它對 alpha 平面本身也做有損壓縮,當你用力放大時,可能在很銳利的邊緣留下幾乎察覺不到的鑲邊。在尋常尺寸與品質 85 下,它維持隱形。要做小尺寸、逐像素精準的圖示,就守著那張 PNG。
各引擎上的實際耗時
轉換程式每個工作階段載入一次,約 800 毫秒抓取再加 300 毫秒轉起來,所以開頭那次轉換披著約一秒暖機。每一次暖跑都跳過它。Chrome 桌面版約 40 毫秒清掉 0.12 百萬畫素,約 250 毫秒處理一個百萬畫素,約 2.8 秒處理八百萬畫素。Firefox 落在後頭,花約四倍長,能把一格 4K 推過 30 秒。Safari 上的 WebKit 落在兩者之間,較靠近 Chrome。中階手機在各方面都比桌面版 Chrome 慢三到五倍。若大檔是家常便飯,桌面版的 Chrome 工作階段就是屋裡跑得最快的位置。
PNG 該維持是 PNG 的時候
就算重量要緊,有幾種工作仍呼喚 PNG。小尺寸的銳利文字,標籤、徽章或圖示尺寸記號上的那種,在 AVIF 裡會招來近看讀起來糟糕的瑕疵。你打算繼續編輯的母檔也屬於 PNG,因為每一趟穿過有損格式,損失都會疊起來。有些去處直接拒收 AVIF,某些文件編輯器、較舊的設計套裝,以及若干電子郵件用戶端就在其中,那些要的是 PNG。第一格之後的動畫在這裡也會掉落,因為這個組合處理一格。其他每一處,要送往現代網站的透明照片與圖形,PNG 轉 AVIF 就是該走的一步。
用數字講的 Core Web Vitals 立論
Largest Contentful Paint,那項頭條載入指標,直接回應頁面上最大那張圖的大小。把那張圖從 116 KB 帶到 16 KB,這個數字是測試時在一張 4K 照片上量到的,會把它在 10 Mbps 線路上的傳輸從約 93 毫秒削到那個元素的約 13 毫秒。把同樣的削減鋪到一面產品網格、一個輪轉的英雄區,或一個被透明圖示塞密的介面,總和會舒舒服服地把 LCP 拖到 Google 讀作良好的 2.5 秒線以下。AVIF 的立論之所以站穩,正因為它能用平實的數字來爭。在接近 94.3 percent 的涵蓋率下,退回稀少到頻寬的收穫蓋過那點額外的 picture 標記。
它與常見線上轉換工具的區別
幾乎每個線上 AVIF 轉換工具都會把你的 PNG 送往遠端硬體,然後依該營運者所持的保留規則保存結果,而這些規則往往含糊不清。Araluma對其運作方式很明確。由於 AVIF 很重,為了得到最乾淨的結果,轉換在我們的伺服器上執行,當伺服器搆不到時瀏覽器中的編碼器會自行接手。當你的檔案到達我們這裡,它會被編碼,然後在大約 2 小時內清除,不要求帳號,也不會用於你發起的轉換之外。沒有長期儲存,也不會分享。對於處理客戶工作、未發布的產品照片或使用者內容的人來說,這筆交易誠實的形態是這樣的:檔案可能經過我們的伺服器,僅為建構你的 AVIF 而被觸及,並且不會逗留。