SmallJPG 免費線上 JPG 壓縮實測，把照片壓到表單規定的大小

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

報名表單、證件照上傳、政府或學校的入口網站，常常只給你一個數字：檔案請小於 50KB。一般壓縮工具給你的是品質滑桿，壓完多大全憑運氣；SmallJPG 給你的是一個 KB 輸入框，你填 50，它就朝 50KB 壓。我在 2026 年 9 月用一張 4,117,088 位元組、2448×3264 的照片實測：目標 50KB，輸出 43,947 位元組，畫面標示「43 KB (98 %)」，一次過關。整個壓縮在瀏覽器裡完成，照片沒有上傳到任何伺服器。

Pin

結論先講：如果你的痛點是「表單規定檔案上限」，SmallJPG 值得放進書籤，但有兩個使用前提。一定要勾選 Manual Size Adjustments 再填目標大小，不勾的話它不會收斂到任何你指定的數字，我的實測輸出是 103KB，連程式碼內建的 100KB 預算都超過；而且要先想清楚解析度，它壓小檔案的主要手段是縮圖，目標 20KB 時，2448×3264 的照片輸出只剩 345×460 像素。大小過關了，解析度卻可能過不了另一關。

四個情境實測：50KB 過關，20KB 只剩縮圖尺寸

我用同一張照片跑了四個情境，數字如下（2026 年 9 月實測，下載後直接量檔案與像素）。

四個數字各自說了一件事。目標 50KB 壓出 43,947 位元組，代表收斂機制真的在做事，而且刻意壓在目標之下。不勾 Manual 的情境輸出 103,272 位元組，是最值得記住的數字，後面會解釋為什麼。目標 20KB 的輸出只剩 345×460 像素，這是大多數人沒預期到的代價。最後一個情境是好消息：來源檔已經比目標小時，它直接把原圖給你，不會為了流程硬轉一次檔、越壓越大。

Pin

標示裡的百分比是縮小率，等於 4.1MB 壓到 43KB 就是 98%，跟畫質無關。想判斷畫質，只能自己把圖打開看；我的 50KB 輸出在螢幕上看是可接受的證件照等級，20KB 那張則明顯是縮圖。

要提醒的是，收斂結果跟照片內容有關。我這張是細節多的漸層測試圖，畫面越單純的照片在同樣目標下能保留的解析度越多，反之雜訊、草地、人群這類細節多的照片會被壓得更小才達標。把 50KB 當成「一定會剩 43KB」不對，把它當成「一定低於 50KB」才是程式碼保證的事。

它怎麼把檔案壓到指定大小：從目標反推尺寸，重試時再同步降品質

它的前端程式碼不長，壓縮邏輯可以直接讀完，收斂的方法分成兩層。

起點在開始壓之前就決定了：畫布的初始邊長，是把目標位元組數除以 40。目標 50KB（50,000 位元組）對應 1,250 像素的框、目標 20KB 對應 500 像素的框，照片等比例塞進這個框。這一步解釋了 20KB 情境為什麼直接變 345×460：2448×3264 的照片塞進 500 像素的框，長邊就是 500 再往下修。目標越小，框越小，這是在降品質之前就寫好的尺寸預算。框比照片大時不會放大，照片維持原尺寸進下一關。

接著是重試迴圈。每次輸出仍然超過目標，就把畫布再縮小 20 像素、品質從 1.0 往下降 0.1，設計上的品質下限是 0.7，剩下的差距交給解析度縮小補足，直到輸出塞進目標為止。因為 JPEG 品質壓到 0.7 以下的收益很差，這是工程上合理的取捨，但對使用者來說，代價就是你填的數字越小、圖被縮得越小。長寬比全程保持：2448×3264 是 3 比 4，輸出 345×460 也是 3 比 4，縮小的是框、不是形狀。還有三個實作細節值得知道：換算用 1KB 等於 1,000 位元組的十進位，不是 1,024；透明背景會被填成白色再轉成 JPEG，PNG 丟進來會失去透明；輸入框留空時它抓 100KB 當預設目標，不是 0。

介面上還有一個 Clear All 旁邊的 Download All，多選檔案壓完可以打包一次下載，打包的 ZIP 工具（JSZip）是選了圖之後才動態載入的。單張下載則是直接產生瀏覽器本機的檔案連結。

不勾 Manual Size Adjustments，就不會收斂到指定大小

首頁預設不勾 Manual Size Adjustments，大小輸入框是藏起來的，很多人會直接選圖開壓。這條預設路徑的行為完全不同：選完圖壓縮立刻自動開始，中間沒有按鈕讓你確認，大小輸入框和 Compress 按鈕都藏在勾選框後面，不勾就永遠看不到。程式碼層面，這個模式品質固定在 0.8，只做一次，不進入重試迴圈。輸入框留空時，程式碼拿 100KB 當計算初始尺寸的內部預算，但沒有任何「壓到 100KB 以下」的保證。我的實測就是這樣跑出 103,272 位元組，連這個內建預算都超出 3%；如果你的表單上限是 100KB，這條預設路徑的輸出會在你以為安全的地方超標。

正確用法是把 Manual Size Adjustments 勾起來，在輸入框填上限，再按 Compress。另外網站還有一整排預先設定好目標的頁面，導覽列上就看得到 50KB、100KB、200KB 幾個專頁，這些頁面會自動帶入大小，效果等同於手動勾選，例如 20KB 頁面的輸出就與手動填 20KB 完全相同（同樣 13,178 位元組、345×460）。要極小目標時，先想一下前面的尺寸預算：把目標填到 5KB，對應的初始框只有 125 像素，輸出基本上是縮圖等級。

照片不出瀏覽器是真的，但這是程式碼的事實，不是站方的承諾

壓縮類工具最該問的一句話：照片有沒有被上傳？我把整個使用流程的網路請求側錄下來，答案可以直接給：沒有。前端程式碼裡沒有任何資料上傳的呼叫，沒有 fetch、沒有 XMLHttpRequest、沒有 FormData，輸出是用瀏覽器的 canvas 產生再包成本機檔案連結。實測一次壓縮連帶載入頁面共 716 個請求，其中沒有任何一個帶著圖片內容，除了網站自己的頁面與腳本，其餘都是廣告與統計端點。這對證件照、身分文件這類敏感圖片是實質的加分：不是「站方說不會上傳」，是架構上根本沒有接收照片的伺服器。

但要把兩件事分開。程式碼證明的是現在這個版本的行為；站方的隱私政策對圖片處理隻字未提，全文只有 Ezoic 廣告聯播網的 cookie 說明，包括 Ezoic 及合作夥伴可能收集 IP 位置、裝置與語言資訊做個人化廣告。換句話說，「不上傳」隨時可能因為改版而改變，而且沒有條款拘束它。如果你要的是有承諾、可長期信任的本機處理，站內有更合適的選擇：MAZANOKE 同樣在瀏覽器裡壓圖、還會清掉位置等後設資料，PicSharp 把引擎放在本機、模式選錯才會上雲端，桌機批次需求則可以看開源工具 Caesium。

還有一個隱私層面的實話：頁面本身嵌了 Google Analytics（GA4）與 Ezoic 廣告，你的瀏覽行為照樣被統計。圖片不出門是真的，瀏覽足跡出門也是真的。

不過重編碼有一個對證件照有利的副產品：後設資料不會存活。我放一張內嵌相機型號資訊的圖進去，輸出檔的 EXIF 是空的；canvas 重新編碼等於生出一張全新的 JPEG，拍攝位置、設備型號這些跟著檔案走的資訊都不在了。這點對要上傳身分文件的場合是實質加分，但要說清楚它與明確主打清後設資料的工具不同：那是它的功能，這裡只是架構的副產品，站方沒有把它寫進任何文件。

「沒有伺服器」也有另一面的含義：壓縮吃的是你自己裝置的資源。這對一張證件照毫無感覺，但一次丟幾十張高解析度照片，舊一點的電腦會明顯變慢、風扇拉高，瀏覽器分頁的記憶體用量也會跟著長。它是為「一次幾張、目標明確」的情境設計的，不是批次生產線。

免費的代價：壓一張圖，連帶近七百個廣告請求

前面那個 716 個請求的數字值得單獨看。其中屬於 SmallJPG 自己的資源只有十來個：頁面、樣式、一份 jQuery、主程式與幾張圖示。其餘都是 Ezoic 廣告系統帶進來的競價與身分同步請求，名單包括 id5、Flashtalking、SmartAdServer 這類廣告技術網域；換個情境再測一次是 662 個，量級穩定。第一次載入還會跳同意管理視窗（CMP），歐洲以外地區多半直接放行。

實際影響是體感而不是功能：在慢速網路或舊電腦上，頁面會比工具本身重得多；開了廣告阻擋器的人體驗會好一截，而且不影響壓縮功能，因為壓縮完全不依賴這些請求。順帶一提，網站把 jQuery 的檔名拼成了 jqery.slim.js，這種小地方透露它是單人或少人維護的小站作品，維運能量有限。

邊界與限制：HEIC、極小目標與匿名站方

檔案選擇器宣告接受 HEIC 與 HEIF，也就是 iPhone 的原始照片格式。這是站方的宣告，我沒有實測解碼結果；瀏覽器對 HEIC 的支援落差很大，Safari 之外常有選了檔卻解不開的狀況。iPhone 用戶比較穩的做法，是先用瀏覽器版的實況照片轉換工具或系統內建轉檔把圖變成 JPG 再上來壓。

其他該知道的邊界：目標大小沒有下限擋（可以填 1），填得越小圖越小，網站不會警告你解析度不夠；沒有品質或解析度的鎖定選項，無法「只降品質、不縮尺寸」；多檔是一次一張排隊壓，不是平行處理；它是網頁工具，沒有離線版本，第一次打開仍需要網路把頁面載下來。網站本身的背景我查過：網域 2023 年 10 月註冊，網際網路檔案館從 2024 年 2 月開始有存檔，三十多筆快照延續至今，是跑了兩年多的老工具站；導覽列上的 50KB、100KB、200KB 專頁與 Increase、Reduce 這類一頁一關鍵字的落地頁，看得出它是為搜尋流量而建，廣告是看得到的收入來源。不過 About 頁沒有公司名稱，頁尾連向 pi7.org 家族的兩個姊妹工具（批次縮圖與 GIF 工具），營運主體維持匿名。工具能用、也活得夠久，但問責對象不存在，這是使用免費小站工具的共通前提。

適合誰，以及其他選擇

SmallJPG 最適合的情境很明確：你的圖卡在明確的檔案大小上限，而且你能接受尺寸跟著縮。證件照、報名表單、有 KB 上限的會員系統，都是「系統只給你一個數字」的場景；勾上 Manual、填上限、下載，三步結束，照片不出瀏覽器。相對地，如果你要的是「畫質盡量好、大小隨緣」的一般壓縮，或需要固定解析度，它反而不如傳統品質滑桿式的工具；批次大量照片或要保留後設資料控制，桌機的開源工具更穩。

判斷尺很簡單：先看表單規定的是只有大小，還是大小與解析度都規定。只規定大小，SmallJPG 是目前最直接的免費解；兩者都規定，先用它的尺寸預算法則（目標位元組除以 40，大約等於輸出的初始邊長）估一下輸出尺寸，估出來低於表單要求的像素下限，就代表你需要改用可鎖解析度的工具，而不是硬壓。舉例來說，表單要求「500KB 以下且寬度至少 600 像素」，500KB 的初始框是 12,500 像素、綽綽有餘，放心用；要求「20KB 以下且至少 800 像素寬」，20KB 的框只有 500 像素，一開始就註定達不到，直接換工具才不會浪費時間。