你壓縮圖片來減小檔案大小，但開啟結果時卻發現圖片看起來模糊、柔和或有色塊。這是關於圖片壓縮最常見的抱怨之一 — 而且幾乎總有可修復的根本原因。好的壓縮目標是：檔案只有原來的一小部分大小，但看起來與原圖相同。以下是五個出問題的原因，以及各自的修復方法。
JPEG 和 WebP 壓縮的工作方式是丟棄演算法認為最不明顯的視覺資訊。質量設定過低（低於 70%）時，演算法丟棄了太多資訊 — 你會看到模糊、塗抹感，或在邊緣和天空/漸變區域出現 8×8 畫素的色塊瑕疵。
修復方法：網頁照片使用 75–85% 質量。80% 是可靠的預設值，可將檔案大小減少 60–80%，同時幾乎沒有可感知的質量損失。低於 70% 只能額外節省 5–10% 的檔案大小，但會明顯降低圖片質量。
每次儲存有失真壓縮的圖片（JPEG、WebP），演算法都會丟棄更多細節。如果你開啟一張 JPEG，稍作修改，再另存為 JPEG，你已經對同一張圖片運行了兩次有損演算法。視覺劣化會疊加 — 第一次壓縮產生的瑕疵被當作影像資料處理，在第二次壓縮中進一步失真。
修復方法：始終以無損格式（PNG、TIFF 或相機 RAW 檔案）儲存原始檔案。只在最終匯出步驟才壓縮為 JPEG，且只壓縮一次。如果你收到一張 JPEG 需要編輯，儘量減少重新儲存次數 — 或接受每次重新儲存都會輕微降低質量的現實。
JPEG 是為具有漸變色彩過渡的照片設計的。它對尖銳邊緣、文字和純色區域處理很差 — 將截圖或 UI 設計稿壓縮為 JPEG 會產生模糊的文字和圖示、按鈕周圍的色塊瑕疵。這不是質量設定問題；這是演算法與內容型別之間的根本不匹配。
修復方法：截圖、UI 設計和帶文字的圖片使用 PNG 或 WebP 無損格式。JPEG 或 WebP 有損格式只用於照片。經驗法則：如果你的圖片有硬邊緣或純色區域，使用 PNG。
如果你壓縮一張 800×600 px 的圖片，卻以 1600×1200 px 顯示（或在需要 2× 解析度的 Retina/HiDPI 顯示器上顯示），瀏覽器必須放大圖片。放大總會模糊 — 畫素在原本不存在的地方被創造出來。這是顯示問題，不是壓縮問題，但它經常被歸咎於壓縮。
修復方法：以實際顯示解析度匯出，並考慮裝置畫素比。對於 Retina 顯示器，以 CSS 畫素尺寸的 2 倍匯出。CSS 中 400px 寬的卡片應使用 800px 寬的圖片。壓縮後不要放大。
社交媒體平臺、郵件客戶端和 CMS 在你上傳後通常會在其伺服器上對圖片進行二次壓縮。如果你的原始上傳已經被大幅壓縮，平臺的二次壓縮會放大已有瑕疵並新增新的模糊。Instagram、LinkedIn 和 Gmail 以激進的二次壓縮著稱。
修復方法：向會二次壓縮的平臺上傳儘可能高質量的版本。反直覺地，上傳更大、更高質量的檔案反而能獲得更好的最終效果 — 讓平臺執行唯一一次壓縮。如果要上傳到會二次壓縮的平臺，不要預先過度壓縮。
| 使用場景 | 格式 | 質量 | 預期大小 |
|---|---|---|---|
| 網頁照片（部落格、作品集） | JPEG 或 WebP | 80–85% | 50–200 KB |
| 電商產品圖 | JPEG | 80–85% | 150–500 KB |
| 社交媒體上傳 | JPEG | 90–95%（高質量） | 500 KB–2 MB |
| 郵件附件 | JPEG | 75–80% | 50–150 KB |
| 截圖 / UI 介面 | PNG | 無損 | 100–500 KB |
| 列印（300 DPI） | JPEG 或 TIFF | 90–95% | 1–5 MB |
網頁使用時，75–85% 質量是最佳平衡點 — 感知上接近無損，但檔案小 60–80%。列印用 90–95%。郵件附件用 70–80%。低於 70% 會在大多數照片上產生可見的色塊和模糊瑕疵。
JPEG 和 WebP 是有損格式。每次儲存有失真壓縮圖片，演算法都會丟棄更多細節。對已壓縮的 JPEG 再次壓縮會放大已有瑕疵併產生新瑕疵 — 視覺劣化會疊加。始終保留原始檔案，每次需要更小版本時都從原圖重新壓縮。
截圖包含硬邊緣、文字和純色區域 — 這正是 JPEG 的 DCT 壓縮演算法處理最差的內容。JPEG 會模糊尖銳邊緣，在純色區域產生 8×8 畫素色塊瑕疵。截圖和 UI 設計稿始終儲存為 PNG 或 WebP 無損格式。JPEG 是為照片設計的，不是為圖形。