如何把 AVIF 轉成 WebP
把一張 AVIF 拖到上傳區，或點一下挑選檔案。瀏覽器會以原生方式讀取那張 AVIF，再用內建功能把像素存成 WebP。兩個步驟都是原生的，所以不必載入模組，也沒有預熱的延遲。桌面瀏覽器上的多數照片，轉換會在一秒之內完成。WebP 準備好時，資訊列會把原本的 AVIF 大小擺在新的 WebP 大小旁邊。點下載就能存到你的裝置，沿用相同的主檔名換上新的 .webp 副檔名。這個 WebP 馬上就能交給任何接受該格式的平台。
正在載入您的檔案…
把 AVIF 轉成 WebP，相容更廣又留住透明度
當你需要更廣的應用程式支援、卻又不想一路退回 PNG 時，就在瀏覽器裡把 AVIF 轉成 WebP。
正在載入您的檔案…
或將圖片拖放至此
轉換中…
0%
正在轉換您的圖片
這可能需要一分鐘左右——多個檔案會稍久一些。請保持此分頁開啟。
圖片已轉換為 WebP
快速解答
把 AVIF 快速轉成 WebP。轉一張圖片就在瀏覽器裡發生：它原生解碼 AVIF，再用內建編碼器存成 WebP，所以單個檔案沒有什麼要上傳，通常不到一秒就好。一次轉好幾張是另一回事：這批會送到我們的伺服器去做事，下載連結會在大約 2 小時後刪除。兩種情況下透明度都保留，因為 AVIF 和 WebP 都有完整的 透明度通道，去背和疊層帶著它們在 AVIF 裡的同一張遮罩進入 WebP。輸出比原始稍大，通常重 20 到 25 個百分點，因為在同等品質下 AVIF 壓得比 WebP 好。你轉換是為了相容，不是為了大小。WebP 被郵件用戶端、較舊的設計工具、社群上傳流程，以及還處理不了 AVIF 的內容系統接受。
為什麼 WebP 檔案比 AVIF 大？
AVIF 是 2026 年最有效率的主流影像格式，在相同畫質下通常比 WebP 小 20 到 25 個百分點。從 AVIF 轉到 WebP，是從較有效率的格式換到較沒效率的格式，所以產出本來就會比較大。這在意料之中，並不代表轉換出了什麼問題。你是刻意做出取捨：放掉一點檔案效率，換 WebP 在各平台與工具間更廣的接受度。產出的 WebP 仍然遠比同一張影像的 PNG 小。相對於在那些還沒跟上 AVIF 的系統上換來的相容性，這個代價並不大。
何時用 AVIF、何時用 WebP
當你從頭到尾掌控整條交付鏈、你的受眾用的是現代瀏覽器、而且每一千位元都要計較時，就留著 AVIF。當目的地還不接受 AVIF 時就轉成 WebP：上傳處理過時的 WordPress 和 Shopify 媒體庫、在遠端伺服器以較舊編碼處理影像的社群平台、會預先處理圖片的電子報平台、老舊的交付設定、較舊的設計工具，以及任何你已經碰過 AVIF 被拒的地方。你並沒有在任何有意義的程度上犧牲畫質，因為近乎無損設定下的 WebP，在正常顯示尺寸看起來就跟那張 AVIF 一樣。你買到的是進入那些還沒跟上 AVIF 支援的系統的門票。
AVIF 轉 WebP 後透明度還在嗎？
在。WebP 支援 透明度通道，AVIF 也是，所以轉換會原封不動保留每一個透明像素。帶柔和陰影的標誌、邊緣羽化的產品去背圖、帶圓角的介面素材，全都會帶著和原本 AVIF 一樣的遮罩抵達 WebP。這是和轉成 JPG 的關鍵差別，JPG 沒有 透明度通道，會把透明區換成純色填滿。色彩平面和 透明度遮罩都會以近乎無損的設定重新儲存，所以 透明邊緣保持乾淨，透明度不會變糊，也不會變成部分填色。轉換前不必手動壓平任何東西。
WebP 的瀏覽器與平台支援
WebP 幾乎被每一款現代瀏覽器支援：Chrome、Firefox、Safari、Edge，還有所有主要的行動瀏覽器。全球支援度超過 97 個百分點。在這個使用情境裡更重要的是，WebP 被接受的平台範圍比 AVIF 廣得多。拒收 AVIF 的電子郵件用戶端，在伺服器先處理過後常常能正確處理 WebP。封鎖 AVIF 上傳的內容系統，通常會接受 WebP。還沒加入 AVIF 的設計工具，照樣讀得了 WebP。如果你的工作流程要讓影像在交付前經過好幾個系統，WebP 是現今比較保險的中介格式。純粹瀏覽器對瀏覽器的交付，AVIF 更有效率，但論在非瀏覽器系統間的相容，WebP 的表現確實更強。
你的檔案在哪裡處理
這要看你轉多少個檔案。轉一張圖片完全跑在瀏覽器自帶的影像引擎裡：AVIF 被解碼，WebP 就地存好，什麼都不往任何地方走。打開開發者工具，切到網路面板，轉一個檔案，你會看到針對圖片的對外請求為零。一次轉好幾張則不一樣：這批去到我們的伺服器，由它做編碼並把結果聚攏，下載連結會在大約 2 小時後刪除。超過那段短暫的視窗，我們既不留帳號，也不留你圖片的副本。所以單張轉換從頭到尾留在你的機器上，而一批在我們的伺服器上處理後被刪除，之後你的東西什麼都不留下。
運作方式
-
放上你的 AVIF
把 AVIF 拖到上傳區，或點一下開啟檔案選擇器，從你的裝置挑一張來開始。
-
等待結果
瀏覽器會以原生方式讀取那張 AVIF 並產出 WebP。兩個步驟都是原生的，所以不載入模組，轉換很快。
-
看一下大小
資訊列會顯示 AVIF 來源大小和 WebP 產出大小。預期 WebP 大約比 AVIF 大 20 到 25 個百分點。
-
下載 WebP
點下載按鈕，把檔案存到你的裝置，沿用相同主檔名換上新的 .webp 副檔名。
相關轉換
當目的地支援時，把 WebP 再壓回 AVIF。或一路轉到 PNG 取得完整的無損觸及。
常見問題
為什麼要把 AVIF 轉成 WebP？
WebP 被接受的系統範圍比 AVIF 廣。電子郵件用戶端、某些版本的 WordPress 和 Shopify 這類較舊的上傳處理器、在遠端伺服器處理影像的社群平台、老舊的交付設定，以及還沒加入 AVIF 支援的設計工具，全都處理得了 WebP。你手上已經有 AVIF 來取得最佳壓縮。當接收你影像的平台還讀不了 AVIF 時，你就需要 WebP。理由是相容，不是檔案大小，而代價是檔案略重一點。
WebP 比 AVIF 小嗎？
不。在相同畫質下，AVIF 通常比 WebP 小 20 到 25 個百分點。把 AVIF 轉成 WebP 會產出略大的檔案，而不是更小的。如果目標是把檔案縮到最小、而目的地又支援 AVIF，那就留著 AVIF。只有在目的地要求時才轉成 WebP。WebP 產出仍然遠比同一張影像的 PNG 小，所以它依舊是相容用途下精簡的中介選擇。
把 AVIF 轉成 WebP 會保留透明度嗎？
會。AVIF 和 WebP 都支援 透明度通道，所以你 AVIF 裡的透明像素會完整寫進 WebP。沒有東西被壓平，也不會補上背景色。這和轉成 JPG 不同，JPG 不支援 alpha，會把每一塊透明區壓平成純色。標誌、去背圖和介面素材在轉換後仍保有柔邊和圓角，隨時可以疊在你放在後面的任何背景上。
把 AVIF 轉成 WebP 會降低畫質嗎？
很少。WebP 的儲存以近乎無損的設定進行，在照片上量到約 44 dB PSNR，在正常顯示尺寸下肉眼分不出和 AVIF 來源的差別。過程有一次重新儲存，所以結果在技術上算有損，但在自然影像上看不出瑕疵。對於邊緣非常銳利或色彩硬切換的圖形，請仔細檢查產出，因為那些區域對任何壓縮變化都比較敏感。
AVIF 轉 WebP 要花多久？
桌面瀏覽器上的多數照片，轉換會在一秒之內完成。AVIF 的讀取和 WebP 的儲存對現代瀏覽器來說都是原生的，沒有模組要載入。一張典型的 200 萬像素照片在 Chrome 上大約 100 到 200 毫秒就完成。即使是大張的 4K 照片，通常也在一秒之內結束。這比反方向快得多，從 WebP 做 AVIF 必須載入一個沉重的功能，並做遠遠更吃力的運算。
哪些瀏覽器支援 WebP？
幾乎所有現代瀏覽器都支援 WebP，而且支援很多年了。Chrome 從第 23 版起支援，Firefox 從 65 版，Safari 從 14 版，Edge 從 18 版。行動瀏覽器跟著相同版本走。全球 WebP 支援度超過 97 個百分點。實際上，只要是 2026 年還在活躍使用的瀏覽器，幾乎一定讀得了 WebP。剩下的少數例外是 Internet Explorer，以及 iOS 13 或更早上的非常舊版 Safari，這些如今很罕見了。
詳細資訊
團隊關於工藝、格式以及一個好結果背後小決定的筆記。
2026 年 AVIF 的相容版圖
到 2026 年，AVIF 的瀏覽器支援達到全球約 94.3 個百分點，但瀏覽器支援並不是全貌。很大一部分的影像消費發生在瀏覽器之外：電子郵件用戶端在內文渲染影像、設計工具開啟檔案來編輯、內容系統驗證並重新處理上傳、交付影像流程、文件編輯器嵌入素材，以及在上傳當下處理影像的社群平台。在多數這類非瀏覽器系統裡，AVIF 的支援遠遠落後於瀏覽器的普及。Gmail、Outlook 和多數企業電子郵件用戶端，仍透過拒收 AVIF 的較舊流程處理影像。Adobe Creative Cloud 直到 2024 年底的版本才加入 AVIF 支援。許多裝著較舊影像外掛的 WordPress 設定，上傳時仍會封鎖 AVIF。相對地，WebP 在這些平台裡已被採用多年。把 AVIF 轉成 WebP，正是跨越這片非瀏覽器地帶的相容橋梁。
為什麼兩邊都跑得快
AVIF 轉 WebP 比反方向快的優勢，來自編碼架構。讀取 AVIF 由原生的瀏覽器解碼器處理，在現代裝置上會用到硬體加速。儲存 WebP 用的是瀏覽器原生的 WebP 功能，在多數平台上也有硬體加速。兩邊都不必載入沉重的模組，而那正是 AVIF 輸出的瓶頸。產出 AVIF 所需的那套功能很龐大，每次工作階段要花大約一秒來初始化。AVIF 轉 WebP 完全跳過這一切。整條流程是經由原生路徑先解碼再儲存，一張 200 萬像素照片的整趟往返，在任何現代桌機或筆電瀏覽器上都遠遠在一秒之內結束。這讓 AVIF 轉 WebP 很適合那種使用者期待一秒內有回應的互動式工作流程。
重新儲存實際付出多少代價
把 AVIF 轉成 WebP 牽涉一次重新儲存。那張 AVIF 原本就以某種程度的有損壓縮產生。把它解碼會得到反映那個有損來源的像素值。WebP 的儲存接著以調到品質 85 的近乎無損設定，對那些像素施加自己的壓縮。在那個設定下，產出在典型照片內容上量到約 44 dB PSNR。對於以正常顯示尺寸看照片的人來說，AVIF 來源和 WebP 產出之間的差別看不出來。對於小尺寸下的極細文字、像素級精準的圖示，或硬邊的色塊，兩次有損處理的累積效果在近看時可能會顯露細微差異。在把整個圖庫全面轉換之前，先在你最在意畫質的素材上，挑一個有代表性的樣本以全縮放檢查。
細看透明度的來回轉換
AVIF 中的透明度編碼為獨立的一層，瀏覽器在讀取檔案時會將它與色彩內容一起解碼。瀏覽器解碼一張 AVIF 時，會產生一個色彩緩衝區和一個 透明度遮罩。轉換會把兩者以完整透明度合成，保留每一個部分透明的像素。WebP 的儲存接著寫出一張有損的 WebP，其 alpha 以 WebP 專門用於 透明度層的無損演算法編碼。結果是產出 WebP 裡的 透明度遮罩，相對於從 AVIF 解出的 透明度值是以無損方式保存。柔和漸層和羽化邊緣都會留下來。唯一存在的 alpha 劣化，是 AVIF 原本編碼時引入的。如果來源 AVIF 有乾淨的 透明邊緣，WebP 產出也會有，帶著相同的遮罩，隨時可以合成到任何背景上。
把產出和其他選項比一比
當你要讓一張 AVIF 能在讀不了 AVIF 的系統上使用時，有三個實際的選項：轉成 WebP、轉成 PNG，或轉成 JPG。對任何帶透明度的素材而言，JPG 是錯的選擇，因為 JPG 沒有 透明度通道，會把它壓平成純色。PNG 產出最大的檔案，通常是 AVIF 大小的三到十倍，只有在你需要無損中介、或目的地明確要求 PNG 時才合適。WebP 落在中間：它帶來通用的現代相容性、保留透明度，產出的檔案通常比 AVIF 大 20 到 25 個百分點，而不是像 PNG 那樣大三到十倍。對於任何不要求無損輸出的相容轉換，WebP 是恰當的中介。
單張在瀏覽器，成批在伺服器
這一對按工作分兩條路跑。單張 AVIF 完全在你的瀏覽器裡沿原生路徑被解碼並重新存成 WebP，所以對一個檔案來說根本沒有上傳，開發者工具在頁面載入後以零對外請求加以證實。這是處理一樁快活以及機密客戶工作、自有產品圖、你更願意留在自己機器上的文件的正確路子。一次轉好幾個檔案則在我們的伺服器上做，因為打包、壓縮、交付一整組正是伺服器擅長的活：檔案上去，被編碼、被打包，再作為一個下載還回來，它會在大約 2 小時後刪除，沒有帳號，也不久存。實際上：單張轉換從不離開裝置，而一批在遠端處理，卻只在下載所需的那段短短視窗裡保留。