# Compress Image

> 把 JPEG、PNG、WebP 壓到指定大小：輸入 200 KB，工具用二分搜尋找出剛好塞得進去的品質。可批次、附前後大小對比，全程在瀏覽器裡完成，不上傳。

- URL: https://bytescope.dev/zh-Hant/image-compress/
- Locale: zh-Hant · Also: [en](https://bytescope.dev/en/image-compress.md) · [ja](https://bytescope.dev/ja/image-compress.md)
- Runs: 檔案不會離開你的瀏覽器 — 全部在本機處理。
- Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile.
- Updated: 2026-09-08

## What it does

幾乎沒有人真的想要「品質 74」。大家想要的是一張能通過上傳表單的照片：欄位寫著上限 2 MB，手機裡那張是 5.4 MB，要做的事就是把一個數字壓到比另一個小，而且照片不能爛掉。所以這頁的主角是目標大小模式。把上限打進去（200 KB、2 MB，表單要求多少就多少），品質那個數字讓工具自己去算：先抓一個值編碼，量出結果真正的位元組數，然後把剩下的範圍砍一半再編一次，從兩邊夾逼，直到落在你給的數字下面一點點。這就是對品質參數做二分搜尋，通常四到六輪收斂，而且每一輪秤的都是真的編碼結果，不是估出來的大小。用手拉滑桿其實在做同一件事，只是慢很多、算術也差很多。

預設不換格式：JPEG 進 JPEG 出、PNG 進 PNG 出，壓完直接丟回原本那張圖待的地方，副檔名一樣，也不會有相容性的意外。真的想知道換格式能省多少，就把並排比較打開，同一張圖會另外編成 WebP 和 AVIF，三種格式在達到你目標的品質下的大小並排給你看。差距通常是真的，該講清楚的取捨也一併講：WebP 現在幾乎不會在任何要緊的地方出問題；AVIF 常常在大小上贏一大截，代價是編碼慢得多（大張照片是幾秒，不是幾毫秒），而且比較舊的軟體、部分桌面看圖程式和少數 CMS 到現在還是打不開。看數字，然後想著這張圖要送去哪裡再決定。

整個資料夾丟進來，一輪跑完，每個檔案都列出壓縮前大小、壓縮後大小、最後停在哪個品質、省了幾成，最上面再給整批的總計一個大字。全部都在你的瀏覽器裡：檔案在本機讀取、在 Web Worker 裡編碼，最後以一般的下載交還給你。不上傳這件事是隱私的答案，但在這頁它同時是速度的答案 — 走伺服器的壓縮工具得把每張圖傳上去、再把每個結果抓下來，所以 20 張的批次等於在壓縮到第一個位元組之前，先做完 40 次網路傳輸。這裡沒有往返成本要付，天花板只有你自己的機器，而且把網路關掉照樣能用。

有件事要講白：這是有損的重新編碼。圖片會被解碼成像素、再以較低的品質編一次回去，所以像素真的會變 — 省下來的 KB 正是從這裡來的，也是為什麼一張 1200 萬像素的照片壓到 100 KB 會比壓到 800 KB 看起來鬆散。如果你要的是「檔案變小但像素完全不動」，該去的是移除中繼資料那一頁：它以位元組為單位把 EXIF、GPS 和縮圖那幾塊切掉，從頭到尾不把圖片交給解碼器，所以輸出跟原檔逐位元相同，只是輕了幾 KB 到幾百 KB。無損能省的就是這麼多，所以它沒辦法把 5 MB 的照片弄到 2 MB 以下 — 但如果你只是需要少個幾百 KB，先拿免費的那份，真的不夠再回來這裡。

## Limits

Does not compress PDFs, videos or GIF animations, and does not upscale or enhance images.

## FAQ

### 「品質 80」到底是什麼的 80？

不是任何東西的 80%：不是像素的 80%、不是原檔大小的 80%，也不是某種絕對畫質的 80%。對 JPEG 來說，這個數字是在挑一組量化表，決定每個 8×8 區塊裡的細節被四捨五入得多兇；對 WebP 和 AVIF 來說，它撥動的是那個編碼器裡對應的旋鈕。刻度是各家編碼器自己的，所以 A 編碼器的品質 80 跟 B 編碼器的品質 80，既不是同一張畫面也不是同一個大小；同樣一個 80，套在雜訊滿滿的夜景和一張平平的截圖上，檔案大小可以差好幾倍。這就是目標大小模式存在的理由：跨圖片還有意義的數字只有「出來的檔案有多大」，所以這個工具直接去量它，而不是叫你相信那個旋鈕。

### 為什麼壓一張已經壓過的 JPEG，畫質掉特別多？

因為你在第一代損失上面又付了第二代。一張 JPEG 本身就已經是解碼器重建出來的畫面，連瑕疵一起算在內。壓它等於把那個重建結果解碼、再量化一次，而且這次會把上一代留下的區塊邊緣和振鈴當成「值得保留的真細節」，這是位元預算最糟的花法。反覆幾次，邊緣和文字周圍就會爛成大家熟悉的那種糊。所以手上有原始檔的時候 — 相機檔、PNG 匯出、編輯軟體的母檔 — 就從那個檔一次壓到位，不要拿壓過的再壓。只有 JPEG 也沒關係，好好壓一次到目標大小不會怎樣；真正傷的是壓五次。

### 壓縮之後 EXIF 中繼資料還留著嗎？

不留。重新編碼會走過 canvas，而 canvas 只認得像素，所以輸出完全沒有 EXIF — 沒有 GPS 座標、沒有相機型號、沒有拍攝時間，也沒有嵌入的縮圖。對大多數人來說這是附加好處而不是損失，壓過的照片同時也是清乾淨的照片。但如果你要清掉的只有中繼資料，就不要為了這個去壓縮：移除中繼資料那一頁會以位元組為單位刪掉那些區塊，像素逐位元保持原樣，比「拿一代畫質換同一個結果」明顯划算。

### 為什麼 PNG 沒有品質滑桿？

因為 PNG 是無損格式，格式裡根本沒有品質這個旋鈕可以轉。每個像素都被原封不動存下來，所以要讓 PNG 變小只有兩條路：把同樣的像素存得更聰明，或是讓不同的像素種類變少。這個工具只做前者：`oxipng` 會重跑 filter 與 Deflate 的選擇，替同一張圖找到更好的編碼方式，所以回來的是同一張圖、只是變小。它不會縮減色盤 — 丟掉顏色是有損的加工，而你選 PNG 正是因為它無損，我們不該在背後替你這樣做。效果比 JPEG 小也比較難預測 — 平面 UI 的截圖可能直接少一半，用 PNG 存的照片幾乎不動。如果一張照片型的 PNG 非得壓進某個硬性大小，誠實的答案是轉成 JPEG 或 WebP，而這頁會用數字告訴你那樣要付什麼代價。

### 目標大小根本壓不到怎麼辦？

搜尋會在品質範圍的最低點撞牆，工具會直接說出來，回報它壓到的最小值，而不是默默塞一個超過你上限的檔案給你。4000×3000 的照片沒辦法變成一張 20 KB 而還有人想看的 JPEG — 走到那一步，能動的旋鈕已經不是品質而是像素數了。先把尺寸縮小再試一次（同一張照片的 1600 px 寬版本大約只要六分之一的位元組），或者把輸出換成 WebP 或 AVIF，同樣的大小它們能給出比 JPEG 明顯好看的品質。並排比較就是為了讓你親眼確認這兩招哪一招真的救得了你。

### 我的圖片會被上傳到伺服器嗎？

不會。檔案用 File API 在本機開啟，解碼與重新編碼都在你自己這個分頁的 Web Worker 裡完成，成品是瀏覽器自己產生的下載。這頁是靜態檔案，背後沒有 API，所以沒有地方可以上傳、沒有佇列要排、不會加浮水印，除了你機器的記憶體以外也沒有檔案大小上限。載入過一次之後把網路關掉照樣能用 — 這剛好也是這個說法最簡單的驗證方式：真的需要伺服器的頁面，網路一斷就當場停擺。

## Related tools

- [Image Format Converter](https://bytescope.dev/zh-Hant/image-convert.md) — 不只是要變小、連格式也要換？到這裡轉。
- [Remove EXIF](https://bytescope.dev/zh-Hant/remove-exif.md) — 只要拿掉中繼資料、像素完全不動？可以無損清掉。
- [Image Pixel Diff](https://bytescope.dev/zh-Hant/image-diff.md) — 壓縮後的結果和原圖，可以逐像素對一下。