拿一張 12 MP 的照片(4000 × 3000 像素),用六種方式匯出。PNG:24 MB。品質 90 的 JPEG:3.4 MB。視覺品質對齊的 WebP:約 2.4 MB。視覺品質對齊的 AVIF:約 1.7 MB。GIF,抖色壓到它那 256 色的上限:6 MB,而且到處都是可見的色帶。SVG 不在這份清單上:它描述的是圖形,而照片不是圖形。
螢幕上是同一張影像,磁碟上卻差了 14 倍。這個差距是工程問題,不是品味問題。每種格式都是一組在特定年份、特定限制下做出的工程決策,而那些決策到今天仍反映在你的頁面載重裡。
本文是這場實驗的決策版:每種格式實際上對你的像素做了什麼、2026 年年中有哪些瀏覽器能解碼、網路真正在傳的是什麼,最後附一張可以直接貼進團隊 wiki 的表。
逐一檢視各種格式
JPEG(1992)。 機制:把影像切成 8 × 8 區塊,用離散餘弦變換把每個區塊轉成頻率,再依人類視覺模型把細節係數往零量化。強項:1990 年代中期以後造出來的每台裝置都解得動,編碼快,對連續色調照片表現極佳。弱項:不支援透明、不支援動畫,銳利邊緣和文字周圍有可見的振鈴,而且每重存一次,品質就再下降一些。適合照片,以及任何必須在哪裡都開得起來的東西。
PNG(1996)。 機制:完全無損。每條掃描線先用預測器過濾,再用 DEFLATE 打包——就是 gzip 裡那套 LZ77 加 Huffman 的組合。強項:像素級精確的輸出、完整 alpha、無所不在的支援。弱項是照片:感光元件雜訊讓預測器失效,一張 12 MP 的照片對原始像素大概只壓得出 1.5:1。適合截圖、UI 擷圖、圖表,以及任何有文字或大片純色的東西。
GIF(1987)。 機制:在最多 256 色的調色盤上做 LZW 壓縮,多個影格打包進同一個檔案。僅剩的強項是動畫在哪裡都播得出來,包括不支援現代格式的電子郵件客戶端。弱項是其他一切:256 色、一位元透明,檔案還比同等內容的影片大得多。適合迷因和小型 UI 循環動畫。
SVG(2001)。 機制:就點陣圖的意義而言,沒有。SVG 是描述形狀、路徑和漸層的 XML,由渲染器按螢幕需要的解析度畫出像素。強項:與解析度無關、幾何圖形體積極小、可以用 CSS 設定樣式。弱項:只對真正是向量的內容有效,而且節點多達數千、濾鏡繁重的極端檔案,代價可能比一張點陣圖還高。適合標誌、圖示、圖表和示意圖。
WebP(2010)。 機制:有損模式借用 VP8 視訊編解碼器的影格內預測,無損模式用空間預測加上 LZ77 式的反向參照。強項:單一格式兩種模式、有損模式也有 alpha、支援動畫,而且在 Google 自己的研究中,同等品質下檔案比 JPEG 小 25% 到 34%。弱項:16383 × 16383 像素的硬性上限,以及比 libjpeg 更吃 CPU 的編碼器。幾乎什麼都適合,這也是它成為網路上 JPEG、PNG、GIF 預設升級路線的原因。
AVIF(2019)。 機制:AV1 視訊編解碼器的靜態影格,裝在 HEIF 容器裡。強項:瀏覽器裡能用的最佳有損壓縮,在 Netflix 2020 年的測試中,同等品質下比 JPEG 小約 50%,外加 10-bit 和 12-bit 色彩、HDR、alpha 和動畫。弱項:編碼確實慢,沒有漸進式渲染(影像要麼整張一次出現,要麼完全不出現),而且極低品質設定下會把紋理抹開,不像 JPEG 那種直接的塊狀偽影。適合照片和主視覺圖,也就是檔案大小最關鍵的地方。
HEIC(2015)。 機制:HEVC 靜態影格,同樣裝在 HEIF 容器裡。強項:壓縮能力和 AV1 同一級別,而且是 2017 年以來每支 iPhone 的預設拍攝格式。弱項是法律問題,不是技術問題:HEVC 被層層專利池包圍,而 Apple 以外的每家瀏覽器廠商都拒絕付錢。它屬於相機膠卷,不屬於網路。
JPEG XL(2021)。 機制:同一個格式下整合兩套引擎,VarDCT 負責有損,模組化模式負責無損,外加一項其他格式沒有的能力:能把既有的 JPEG 無損重壓縮到大約原本 80% 的大小,像素逐位元不變。強項:漸進式解碼、出色的無損壓縮比、高保真攝影。弱項是採用率,這主要是瀏覽器廠商之間的政治問題,後面會談。適合攝影管線和檔案典藏,在 Apple 裝置上也適合網路使用。
瀏覽器支援,2026 年年中
各格式預設開啟的版本,依 caniuse 資料:
| 格式 | Chrome | Edge | Firefox | Safari |
|---|---|---|---|---|
| WebP | 32(2014 年 1 月) | 18(2018 年 11 月) | 65(2019 年 1 月) | 14(2020 年 9 月) |
| AVIF | 85(2020 年 8 月) | 121(2024 年 1 月) | 93(2021 年 10 月) | 16.4(2023 年 3 月) |
| JPEG XL | 145,需開啟旗標(2026 年 2 月) | 無 | 需開啟旗標 | 17(2023 年 9 月) |
| HEIC | 無 | 無 | 無 | 17(2023 年 9 月) |
這張表有三個細節值得注意。iOS 上的 AVIF 技術上在 Safari 16.0 就到了,但不支援動畫;16.4 才是 macOS 和 iOS 雙雙完整支援的版本。Edge 明明就是 Chromium,AVIF 卻比 Chrome 晚了幾年才支援,因為 Microsoft 把解碼器關得比 Google 久。而 JPEG XL 那一列背後有一段不尋常的插曲,後面有專門的小節介紹。
全球覆蓋率,依 caniuse 的 2026 年數據:WebP 約 97%,AVIF 約 93% 到 94%。JPEG 和 PNG 實際上是 100%,而且這一點不太可能改變。
相容性階層
按觸及範圍分組,這些格式可以分成五個層級。
第一層是通用組:JPEG、PNG、GIF 和 SVG。每個瀏覽器、每個電子郵件客戶端、每個作業系統預覽窗格、每台十年前的資訊站都解得動。檔案如果無論如何都必須開得起來,就用這四者之一。
第二層是 WebP,獨自一層。最後一個主要缺口是 Safari,而 Safari 14 在 2020 年 9 月補上了它。剩下的只有 Internet Explorer 的安裝存量和非常老舊的 Android WebView。對網站而言(有別於電子郵件),WebP 大約五年來都是安全的預設選項。
第三層是 AVIF。Chrome 在 2020 年有了它,Firefox 在 2021 年,Safari 在 2022 年(完整支援是 2023 年 3 月的 16.4),Edge 在 2024 年 1 月預設開啟。從 2024 年初起,每個主要引擎開箱就能解 AVIF。剩下的幾個百分點是舊 iPhone 和缺乏統一管理的 Windows 電腦,而這正是後備方案的用途。
第四層是 JPEG XL,卡住了。Apple 從 2023 年 9 月的 Safari 17 起原生支援。Google 在 2022 年底移除了 Chromium 的實驗性解碼器,2023 年 2 月的 Chrome 110 生效,之後改變方向,合併了一個 Rust 寫的解碼器(jxl-rs),隨 2026 年 2 月的 Chrome 145 推出,但仍需開啟旗標。Firefox 多年來一直有一個藏在旗標後面的解碼器。所以 2026 年年中的 JPEG XL 支援,意思是全體 Apple 使用者,加上 Chrome 和 Firefox 使用者裡會去開旗標的極少數,這個群體太小,沒辦法作為開發依據。
第五層是 HEIC:Apple 平台上的 Safari 17,其他什麼都沒有。與其說是一個層級,不如說是單一廠商的生態系。
網路實際上在傳什麼
支援不等於使用。HTTP Archive 的 Web Almanac 爬了數百萬個真實頁面,統計它們實際傳了什麼,而 2024 年版(最新一版有完整媒體數據的)讀起來像冰川移動一樣緩慢。JPEG 仍是單一最常見的格式,佔所有影像的 32%,但已經從 2022 年的 40% 掉了整整八個百分點。WebP 拿下其中三個百分點,來到 12%。SVG 多了約兩個百分點。AVIF 到了大約 1%,聽起來像四捨五入的誤差,直到你換成相對的角度來看:兩年成長了近 4 倍。ICO 保有 1.3%,幾乎全是 favicon。至於 GIF,已經 37 年了,居然還漲了一個百分點。
為什麼動得這麼慢?主要有三個阻力。CDN 快取:影像以 URL 為鍵存放在邊緣節點上,換格式意味著讓快取失效、把整個圖庫重新編碼。舊裝置:支援度圖表說 97%,但缺的那 3% 集中在低價 Android 手機和企業機群上,而有些網站承受不起因為一張打不開的圖而丟掉任何一筆訂單。工具慣性:CMS 產生 JPEG 縮圖,因為它一向如此;設計工具匯出 PNG,因為那是最顯眼的按鈕;而改預設值意味著去修改一條沒有負責人的建置管線。
還有編碼成本。AVIF 的壓縮優勢是用編碼時的 CPU 換來的,這就是影像 CDN 要對它收費的原因,也是聰明的團隊選擇在建置或上傳時預先產生 AVIF、而不是即時編碼的原因。
接下來往哪走
AVIF 是未來幾年最穩妥的選擇。它在設計上免權利金(開放媒體聯盟 2015 年由 Amazon、Cisco、Google、Intel、Microsoft、Mozilla 和 Netflix 成立,明確目的就是逃離 HEVC 式專利池),單一規格同時涵蓋有損和無損,支援 HDR,而且已經跨過那個讓後備鏈成本幾乎為零的支援門檻。實際的成本是編碼時間,以及缺少漸進式解碼。預先產生可以解決前者;後者則是合理的取捨。
JPEG XL 本應得到更好的結果。單論技術價值,它是史上被標準化過的最完整的格式:漸進式解碼、最好的無損模式、高位元深度攝影,以及對整個既有 JPEG 存量的無損重壓縮。Google 以生態系興趣不足為由把它從 Chromium 移除,恢復支援的請求隨後成了 Chromium 追蹤系統史上被加星最多的議題之一。三年後 Google 撤回了這個決定,但到那時,採用的窗口期大致已經過去了。在 JPEG XL 流放的這段時間,AVIF 拿下了 CDN 整合、CMS 外掛和預設勾選框。JPEG XL 會以檔案典藏者最愛的身分活下去,也會在 Apple 裝置上保有一等公民的地位。它具備邁入主流的技術條件,卻仍然錯過了。
HEIC 不會成為網頁格式。原因和品質無關。HEVC 解碼需要專利授權,而免費瀏覽器的廠商十年來一直拒絕付這筆錢,何況網路本就建立在免權利金的技術之上。四大引擎裡有三家不肯解的格式,不是網頁格式;它是一個你要在邊界上解決的匯出問題。
至於過渡技術,已經相當成熟,而且有兩種形式。伺服器端內容協商:瀏覽器送出一個 Accept 標頭,列出它能解碼的格式,由伺服器或 CDN 為同一個 URL 挑選最佳變體。客戶端:<picture> 元素,列出候選清單,讓瀏覽器取用第一個它看得懂的:
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>
最底下的 <img> 是通用後備,所以任何地方都不會壞。這就是你把 AVIF 發給那 93%、把 JPEG 發給剩下的人,又不用維護兩個網站的方法。
決策表
| 使用場景 | 該傳的格式 | 原因 |
|---|---|---|
| 照片 | AVIF,後備 WebP 和 JPEG | 照片是位元組節省最多的地方 |
| 截圖、UI 擷圖 | PNG,或無損 WebP | 文字和銳利邊緣必須保持像素級精確 |
| 標誌和圖示 | SVG,後備 PNG | 向量可以縮放到任何密度;最後才點陣化 |
| 頁面上的短動畫 | 優先用影片(MP4/WebM),只有追求最大觸及時才用 GIF | 動畫 WebP 和 AVIF 在瀏覽器裡都能用,但影片的壓縮效果好得多 |
| Favicon | 追求最大觸及用 ICO,現代瀏覽器用 PNG 或 SVG | ICO 是一個可以裝 PNG 影格的容器 |
關於 favicon 補充幾句,因為表格那一列省略了一些細節。現代瀏覽器接受 PNG 甚至 SVG favicon,但 ICO 仍是每個爬蟲、每個 RSS 閱讀器、每個老舊瀏覽器分頁都看得懂的唯一格式,而且一個 ICO 檔案可以把好幾種尺寸打包進同一個容器。如果你的標誌目前是別的格式,JPG 轉 ICO、WebP 轉 ICO 和 PNG 轉 ICO 可以直接在你的瀏覽器裡產生正確的多尺寸 ICO。
格式之間的轉換
大多數轉換工作都能從上面的章節推導出來。目前最常見的一件,是把 HEIC 從 iPhone 轉出來,變成世界其他地方開得起的東西。要分享的話,HEIC 轉 JPG 是對的做法,因為 HEIC 本來就是有損的,而 JPEG 不會讓損失繼續疊加。HEIC 轉 PNG 把目前的狀態凍結起來供編輯使用,而目的地是網站的話,HEIC 轉 WebP 就說得通。
再來是 JPEG、PNG、WebP 這三者的組合。把 JPEG 送進設計流程:JPG 轉 PNG,不是因為品質會變好(不可能),而是因為它從此不再繼續損失。為網頁縮小體積:JPG 轉 WebP。反方向走,為了舊軟體:WebP 轉 JPG 和 WebP 轉 PNG。一張要進相簿的 PNG 截圖:PNG 轉 JPG,或者想要更小的檔案又保住透明,選 PNG 轉 WebP。如果你手上有一批未壓縮的 BMP 掃描檔,BMP 轉 JPG、BMP 轉 PNG 和 BMP 轉 WebP 都比把好幾 MB 的老檔案用電子郵件寄來寄去好。連文件也會遇到同一個岔路:照片型頁面選 PDF 轉 JPG,文字必須保持銳利就選 PDF 轉 PNG,頁面要上網就選 PDF 轉 WebP。
以上每一個工具都在你的瀏覽器本機執行轉換,檔案不會離開你的裝置。
格式會一直改變,規則不會:讓編解碼器配合內容,並在內容改變用途時進行轉換。
