每一種圖片格式都是一組取捨，而不是一張畫質排行榜。PNG vs JPG 是大多數人真正需要的那個比較：JPG 會丟掉你不太可能注意到的細節，換取相片的小體積；PNG 逐個像素完整保存，讓圖形經得起反覆編輯；WebP 則試著把兩者放進同一個容器。

所以真正有用的問題不是「哪種格式最好」，而是「這張圖是什麼、要送到哪裡」。同一個標誌、同一張旅行相片、同一張截圖，答案各不相同，選錯就要在體積或畫質上付代價。

01PNG vs JPG：先講結論

這個問題通常以「PNG 和 JPG 有什麼分別」的形式出現。一句話答案：JPG 是給相片的失真格式，PNG 是給圖形的無失真格式。想要檔案小就用 JPG；想要像素精確、有硬邊、有文字或有透明背景，或者之後還要再編輯，就用 PNG。

先說一個命名問題：JPG 和 JPEG 是同一個格式。JPEG 是標準名稱，.jpg 只是早期 Windows 與 DOS 留下的三個字母副檔名。所以 jpeg vs png 與 jpg png 比的是同一件事，是失真編碼器對上無失真編碼器，而不是同一個格式的兩種畫質等級。

png vs jpg 只是把兩個字對調，答案一樣，唯一改變的是轉換的方向。

三種網頁格式在真正決定答案的屬性上這樣排：

02什麼時候用 JPG、什麼時候用 PNG

把手上這張圖跑過以下五個問題，答案通常就很清楚。

• 是相片，又不需要透明背景？ 用 JPG；如果網站由你控制輸出，用 WebP。
• 是標誌、圖標、截圖或介面素材？ 用 PNG，硬邊與文字保持銳利，還能帶透明背景。
• 要疊在任何背景上？ 用 PNG 或 WebP；JPG 沒有透明通道，透明區域會被壓平成純色。
• 要送去印刷、電郵或較舊的軟件？ 用高質素 JPG，它是接受度最高的選擇。
• 之後會反覆編輯？ 保留 PNG，最後才輸出一次 JPG。

如果你手上是 JPG 但需要透明背景，先用 JPG 轉 PNG 轉換，再到編輯器裡加上透明通道。如果你手上是 PNG 但需要一個所有系統都接受的小檔案，就往另一邊走，用 PNG 轉 JPG。

03每種格式各自在解不同的問題

幾乎所有格式選擇都由三個性質決定：編碼器能不能丟資料、圖片需不需要透明通道，以及內容是相片還是平塗圖形。

失真編碼器（JPG、WebP、AVIF）會刻意減少資訊，再把省下的位元花在更重要的細節上；無失真編碼器（PNG）原樣保存你給它的內容，之後再靠通用壓縮演算法收窄。兩者不是抽象的「畫質高低」，而是在回答不同的問題。

第二個性質是透明通道，也就是讓標誌能疊在任何背景上的逐像素不透明度。JPG 完全沒有透明通道，編碼前必須先把透明區域壓平到某個純色上；PNG 與 WebP 都帶透明通道，WebP 還是失真模式下就支援。

04同一張圖的實測體積

談格式體積，只有在輸入固定的時候才有意義。我們拿一張 1408x768 的相片（public/design/image-compressor-sample.jpg，272,551 位元組），在 Python 3.9.6 / macOS 26.5.1 上用 Pillow 11.3.0 以各編碼器的標準設定重新編碼，以下數字於 2026-10-09 重跑：

input  image-compressor-sample.jpg   1408x768   272,551 B

JPEG  quality 80, optimize           236,333 B   基準
PNG   lossless, optimize           1,733,498 B   比 JPEG 多 633%
WebP  quality 80, method 4           186,492 B   比 JPEG 少 21%
AVIF  quality 50                     117,794 B   比 JPEG 少 50%

這個差距就是全部的故事。PNG 在相片上產出比 JPEG 大 7.3 倍的檔案，因為一旦你拒絕丟掉任何資訊，相片的雜訊幾乎無法壓縮。WebP 在相近的質素設定下比 JPEG 小 21%，AVIF 又更遠。

PNG 不是可以往上轉的畫質旋鈕。

把相片從 JPG 轉成 PNG 不會改變任何一個像素，只會讓檔案變成好幾倍大。JPEG 先前丟掉的細節已經不在了，PNG 只能保證之後不再遺失。

05JPG：相片用的格式

JPEG 以 8x8 像素區塊 為單位，把每個區塊轉成頻率係數後做量化：保留粗略的係數，丟掉肉眼不容易察覺的細節。色度通常還會以一半或四分之一的解像度儲存，因為人眼對亮度遠比對色彩敏感。

這個設計讓 JPG 在相片上勝出、在其他內容上落敗。相片有大量平緩漸變與雜訊可以揮霍，所以強力量化看不出來；截圖則由硬邊與平塗色塊組成，正好是量化最容易破壞的內容，這也是文字存成 JPG 後每個字周圍都會長出灰邊的原因。也因為這樣，jpeg vs png 沒有單一贏家：該用哪一種，取決於內容，而不是分數高低。

內容是相片、目標系統要求最大相容性、檔案要送去印刷或存檔時，就用 JPG。若之後還要重新編輯，請保留一份無失真母檔，因為每一次重新存檔都是從上一次的壓縮結果出發，而不是從原始檔。

06PNG vs JPG：透明與文字

JPG 把位元花在平緩色調上，PNG 則把位元花在精確度上。PNG 在設計上就是無失真的。它保存 24 位元色彩加上 8 位元透明通道，接著先套用逐列濾鏡、把平緩的列變成大量連續零值，再用 DEFLATE 壓縮。這套流程對平塗圖形非常有效：我們那個 1161x389、帶透明背景的標誌存成 PNG 是 98,032 位元組，同樣的像素換成無失真 WebP 只要 36,116 位元組。

它的優點與缺點是同一個性質。因為什麼都不丟，一張 PNG 可以反覆解碼、編輯、重新編碼上百次而不累積損傷，這正是標誌、圖標、示意圖或之後還會調整的介面截圖需要的。

代價會在內容不再平塗的那一刻出現。硬邊圖形壓得很好，相片漸變則否。如果你的 PNG 大得莫名其妙，那其實是檔案在告訴你：這個內容該交給允許丟資料的格式。

07WebP：網頁上通常最好的預設值

WebP 是一個容器，而不是單一編碼器。它同時支援失真壓縮、無失真壓縮、兩種模式下的透明通道，以及動畫，所以一種格式就能取代頁面上的 JPG、PNG 與 GIF。

在我們的實測中，質素 80 的失真 WebP 是 186,492 位元組，同一質素設定的 JPEG 是 236,333 位元組，相片上小 21%。Google 自家的測試同樣顯示，失真 WebP 在相同畫質下比 JPEG 小 25–34%。換成帶透明背景的標誌，無失真 WebP 是 36,116 位元組，PNG 是 98,032 位元組，像素完全不變的情況下少了 63%。

目前版本的 Chrome、Safari、Firefox、Edge 都能顯示 WebP，過去最常聽到的反對理由已經失效。還需要保留 JPG 或 PNG 副本的理由只剩目標系統相容性：印刷廠、較舊的桌面編輯器與部分內部系統仍只接受舊格式。

網頁用 WebP，母檔留原始格式。

要放上網的副本用 JPG 轉 WebP 或 PNG 轉 WebP 轉換，相機原始 JPG 或分層 PNG 留著以便重新編輯。

08按用途選格式，而不是按習慣

如果只記得一列，就記第一列：網頁上的相片預設用 WebP，JPG 當備援；換成硬邊或需要透明的內容，順序就反過來。

09其他你也會遇到的格式

前三種大致能應付多數工作，但還有四種格式出現的頻率高到值得認識。

其中 AVIF 最值得留意。它在我們實測的四種編碼器裡體積最小，目前的主流瀏覽器也都支援，但編碼明顯較慢，部分桌面軟件仍然拒絕開啟。

10會讓你損失畫質或多花位元組的錯誤

「每存一次就爛一次」這件事常被誇大。把測試相片以質素 80 連續重新編碼五次，第一次平均每像素變動 2.45（滿分 255），之後四次依序是 0.12、0.06、0.03、0.02，真實但很小。真正會看出損傷的是把重存與低質素設定、大幅裁切或縮放混在一起，所以安全的習慣是：無失真編輯，只輸出一次。

轉檔不等於修復。

把已經壓縮過的檔案搬進無失真容器，只會保留原有的壓縮損傷。要拿回細節，你需要的是原始拍攝檔，而不是換一個副檔名。

11不經上載，直接在本機轉換

圖片壓縮工具 接受 JPG、PNG、WebP 或 AVIF，並在你的瀏覽器裡重新編碼，可以維持原格式或一個設定就切換格式。上載不會離開裝置，所以不必排隊等伺服器，事後也沒有檔案要清理。

1. 把圖片拖進拖放區，或點擊瀏覽選檔；批次拖放也支援。
2. 清單中的每個檔案都會顯示原始體積與尺寸。
3. 在整合頁按 Compress，或在專用頁（例如 PNG 轉 WebP）按唯一的 Convert 按鈕。
4. 檢查轉換前後預覽，報告會顯示每個檔案省下的百分比。
5. 逐個下載檔案，或按 Download all 一次下載整批。

專用頁把輸出格式與質素固定住，因此沒有參數要調：JPG 轉 WebP 與 PNG 轉 WebP 使用質素 80，WebP 轉 JPG 與 PNG 轉 JPG 使用質素 85，兩個轉成 PNG 的頁面則維持無失真。按錯頁面也可以救回，把結果丟進反向頁面再轉一次就好。

12資料來源

• ITU-T Recommendation T.81 — 連續色調靜態影像的數位壓縮與編碼（取用日期：2026-10-09）
• W3C — PNG Specification (Third Edition)：通道深度、濾鏡與 DEFLATE 壓縮步驟（取用日期：2026-10-09）
• RFC 1951 — DEFLATE Compressed Data Format Specification（取用日期：2026-10-09）
• Google WebP — 壓縮技術、無失真模式與動畫（取用日期：2026-10-09）
• Google WebP — WebP、PNG、JPEG 壓縮比較研究（取用日期：2026-10-09）
• Can I use — WebP 圖片格式的瀏覽器支援（取用日期：2026-10-09）
• Can I use — AVIF 圖片格式的瀏覽器支援（取用日期：2026-10-09）
• MDN — Image file type and format guide：失真與無失真格式、透明通道與各格式強項（取用日期：2026-10-09）
• W3C — GIF89a 規格：色彩表大小與調色盤（取用日期：2026-10-09）
• Nokia — High Efficiency Image File Format (HEIF)（取用日期：2026-10-09）