Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
壓縮塢 Media Compress Hub 開源壓縮工具：圖片 GIF 影片本機壓縮不上傳，跟 tools.video 差在哪？
壓縮塢 Media Compress Hub 是 AGPL-3.0 開源的純前端媒體壓縮工具，圖片、GIF、影片全程在你瀏覽器或桌面視窗裡處理，檔案不上傳任何伺服器，還能指定「壓到 20MB 以內」這種目標體積。底層用 FFmpeg.wasm 與 Web Worker，可裝成 PWA，也透過 Electron 打包成 Windows／macOS／Linux 桌面版（已發布預編譯安裝包）。臨時壓錄屏、縮素材很順手；長期大量壓超大影片仍不如 HandBrake 穩定。
用 AI 摘要這篇文章：
壓縮塢 Media Compress Hub 把圖片、GIF、影片縮檔收進同一個瀏覽器頁面，而且整個處理過程在你自己的電腦上跑，檔案不會被傳到第三方伺服器。它本質上是一份 AGPL-3.0 授權的網頁應用原始碼，你可以直接打開官方示範站用，也能自己架一套、或裝成 Windows、macOS、Linux 桌面軟體。它真正和一堆「免費線上縮檔」網站拉開距離的，是兩件事：處理發生在你本機，以及你能指定一個目標檔案大小，讓工具自己想辦法把影片縮到那個數字以內。
TL;DR：壓縮塢 Media Compress Hub（GitHub 約 37 顆星，AGPL-3.0 開源，React 19＋TypeScript＋Vite，底層用 FFmpeg.wasm 處理 GIF 與影片、Web Worker 處理圖片；2026 年 4 月開張、6 月仍在更新）是純前端的本機媒體縮檔工具，圖片、GIF、影片全程在你瀏覽器或桌面視窗裡跑，檔案不上傳任何伺服器。它支援指定目標大小的智能壓縮、原圖對比預覽，也能透過 Electron 打包成三平台桌面版（已發布預編譯安裝包）。臨時壓一段錄屏、縮一張素材很順手；長期大量壓超大影片，仍不如 HandBrake 這類成熟桌面軟體穩定。
目錄
壓縮塢、tools.video、Squoosh：同一條路線，三種定位
TechMoon 之前介紹過〈tools.video〉這個免上傳的瀏覽器影片工具箱，也介紹過 Google 出的〈Squoosh〉本機縮圖。壓縮塢走的是同一條「把算力搬到使用者電腦」的路線，技術底層也都是 FFmpeg.wasm 搭配 Web Worker，差別在定位：tools.video 是一個已經包裝好的線上工具箱，你打開就能用；壓縮塢則是一份你能下載、修改、自己部署的開源專案。
也就是說，想臨時壓個檔，tools.video 和壓縮塢的示範站用起來差不多；但若你所在的公司不允許把素材丟上任何第三方網站、或你想在內部架一個常駐的縮檔服務，壓縮塢那份 AGPL 原始碼才是能搬回家的東西。它也比只處理靜態圖的 Squoosh 多了 GIF 與影片這一塊，把不同媒體收進同一個介面。下面這張表把幾個常被拿來比較的工具放一起，方便對照各自涵蓋的範圍（tools.video 的部分細節以其官方說明為準）：
| 工具 | 處理位置 | 圖片 | GIF | 影片 | 開源可自架 | 目標大小 |
|---|---|---|---|---|---|---|
| 壓縮塢 | 本機瀏覽器／桌面 | 有 | 有 | 有 | 有（AGPL-3.0） | 有 |
| tools.video | 本機瀏覽器 | 無 | 無 | 有 | 否 | 未確認 |
| Squoosh | 本機瀏覽器 | 有 | 無 | 無 | 有（Apache-2.0） | 無 |
| HandBrake | 本機桌面軟體 | 無 | 無 | 有 | 有（GPL-2.0） | 無 |
為什麼能在瀏覽器裡壓縮，卻不用上傳
多數人對「線上縮檔」的直覺是：檔案得先傳到某台伺服器，伺服器壓完再傳回來。壓縮塢之所以能不上傳，靠的是瀏覽器這幾年長出來的本地運算能力。你把檔案拖進網頁時，檔案是被頁面上的 JavaScript 直接讀進瀏覽器記憶體，不經過任何網路請求；接著一個編譯成 WebAssembly 的 FFmpeg（也就是 FFmpeg.wasm）在瀏覽器的沙盒裡執行轉碼，靜態圖則交給另一條獨立的 Web Worker 處理；壓完的結果再由瀏覽器觸發下載，存回你自己的硬碟。
整段過程，檔案從頭到尾沒有離開過你這台機器。正因為運算不吃站長的伺服器頻寬，它才有可能讓使用者把單檔上限拉到很大，而沒有「免費版限制 100MB」那種成本考量；運算負擔則全部落到你的 CPU 和記憶體上，這點會直接決定它在你機器上跑得多順。
兩個運作細節會影響使用體驗。FFmpeg.wasm 本身是一包編譯成 WebAssembly 的程式，體積有數十 MB，第一次打開網頁時瀏覽器要把它下載下來才開始能縮，之後會被快取住，同一台機器重複使用就不必再等。它的設定頁還把不少參數開出來給你調：單檔大小上限、圖片最低品質、影片的 CRF 範圍與預設偏好都能改，等於你可以在自家環境先把一套慣用參數設好，之後每次縮檔都照這個基準走。
另外有一個比較少被提起的工程限制：FFmpeg.wasm 若要開多執行緒加速，會用到瀏覽器的 SharedArrayBuffer，而出於安全考量，瀏覽器只允許在「跨來源隔離」（cross-origin isolation）的頁面上啟用它，也就是主機得加上 COOP、COEP 這幾個 HTTP 回應標頭。這層隔離有沒有設好，會直接影響 FFmpeg.wasm 能不能開多執行緒；沒設好的話縮檔仍能用，只是可能退回單執行緒、速度慢一些。所以自己部署時，確認主機加上這兩個標頭是跑出應有速度的前置條件（Vercel 可在 vercel.json 設定，一般靜態主機則在伺服器設定檔加入）。
圖片、GIF、影片，分開處理
壓縮塢把不同媒體分開處理。靜態圖這條線支援 JPEG、PNG、WebP、BMP、AVIF 等常見格式讀入，匯出則限定 JPG、PNG 或 WebP（即使讀進來的是 AVIF，也只能轉成這三種，想要更小的 AVIF 輸出得另找專門工具），能調品質、設目標大小，還附原圖與縮完的對比預覽。這層「壓完先看一眼差多少」的設計，和〈Recompressor〉那種用曲線圖列出多種畫質組合的思路相近，只是它更偏向直接給你一個目標值，而不是丟出一整排選項讓你自己挑。
GIF 動圖是壓縮塢比較少見的能力，因為多數線上縮檔工具只處理靜態圖或影片，GIF 落在中間一個尷尬的位置。它用 FFmpeg 對 GIF 重編碼，你能調的包括幀率上限（降幀率是縮 GIF 體積最有效的手段，因為 GIF 每一幀都是一張完整圖）、調色盤顏色數（從 256 色降到 128 或 64 色，大小能再砍一截，但色彩漸層會出現色階）、抖動演算法（決定降色後雜點的分布方式，影響觀感），以及最大寬度。這幾個開關搭起來，同一張 GIF 能壓出從「幾乎無損」到「大小只剩三分之一」的各種結果，比〈MP4 轉 GIF〉那類只做格式轉換的工具，多了對動圖本身大小的掌控。
影片同樣用 FFmpeg，走 CRF 壓縮，可以選擇保留並重編碼音軌，或直接把音軌拿掉只留畫面（例如把一段教學錄屏壓小一點純看操作，就能順手去掉音軌省空間）。所有縮檔任務的摘要會存在瀏覽器本地的 IndexedDB 裡，能在「歷史」頁回頭查看，不用自己記哪次壓成什麼樣。
壓完要匯出成哪種格式
縮圖的最後一步是挑匯出格式，這個選擇會直接影響大小和畫質。放上網頁的素材，WebP 通常是首選，同樣畫質下比 JPEG 小一截，現代瀏覽器也全部支援；如果要最大相容性、給舊系統看，才退回 JPEG；需要透明背景的 logo、去背圖就得用 PNG，但 PNG 通常壓不太動大小。輸出格式和品質參數都可以在壓之前調，搭配原圖對比預覽，能邊壓邊看不同格式之間的取捨，比起只給你一個結果的縮檔網站，多了一層判斷空間。想更系統化地批次處理 WordPress 站台的影像，則可以再搭配〈ShortPixel〉或〈AnyWebP〉，把轉檔與最佳化接進發布流程。
想在內部架一套縮檔服務的話
壓縮塢的網頁版是一個純靜態前端，建置產物就是一堆 HTML、CSS、JavaScript，部署門檻很低。基本流程是把專案原始碼clone 下來，跑 npm install 裝好相依套件，再 npm run build 產出 dist 目錄，把這個目錄丟上任何靜態主機就行，例如 Vercel、GitHub Pages 或自家的物件儲存加 CDN。因為運算都在使用者端，伺服器只負責送出網頁檔案，幾乎不吃後端資源，就算同時多人使用也不會湧入大量運算流量。部署時記得回頭確認前面提過的 COOP／COEP 標頭有沒有設好，這關係到 FFmpeg.wasm 能不能開多執行緒。
這條路特別適合兩種情境：一是公司資安規定素材不能離開內網，自己架一套在內部主機，員工打開就能壓，檔案自始至終不出去；二是想把縮檔能力嵌進既有工作流程，例如設計師交稿前統一在內部站縮圖。只要留意下面的授權但書就行。
桌面版與 AGPL 授權
有一份資訊需要更新：壓縮塢在 2026 年 6 月初對外介紹時，還沒有可直接下載的桌面安裝包，但這個情況已經改變。專案隨後透過 Electron 打包，並在 GitHub 的 release 頁發布了三平台的預編譯版本：Windows 有 NSIS 安裝版與 Portable 免安裝版，Linux 有 AppImage、DEB 和 tar.gz，macOS 則提供 arm64 架構的 DMG 與 ZIP（Intel Mac 沒有對應的預編譯包，得自己編譯）。想用桌面版的人直接下載即可，不必再從原始碼自己 build。從下載次數看，它目前還是個剛起步的小專案（Windows 安裝版累積約三十幾次、macOS 的 DMG 個位數），把穩定度期待放在「夠用」而不是「久經考驗」會比較踏實。
多數人直接用網頁版或裝桌面版就夠，不太需要碰授權條款。壓縮塢用的是 AGPL-3.0，這條授權的關鍵觸發條件是「網路可存取」：只要你修改了原始碼、又把它部署成一個別人能透過瀏覽器存取的服務，就必須依條款公開你改過的源碼。純粹本地自用、或原封不動部署官方版本，則不在這個範圍裡。所以判斷要不要在意 AGPL，標準其實很具體：會不會改、會不會對外開放存取；兩個都「否」，就基本不用管它。
幾個會卡到你的限制
這套工具的天花板，說到底是瀏覽器分頁能動用的記憶體。wasm 版的 FFmpeg 運作時會把整段媒體載進瀏覽器記憶體裡處理，檔案越大、佔的記憶體越多；一旦逼近分頁的記憶體上限，瀏覽器可能直接終止這個分頁（就是你偶爾會看到的「這個分頁發生問題」），而不是硬撐著跑完。所以專案標示的圖片 50MB、GIF 500MB、影片 5GB 是理論上限，而且單檔上限在設定頁可以自己調，但能不能真的壓到 5GB，取決於你這台機器有多少記憶體，不是工具本身的限制。
目標大小這個功能也要設對預期。它是一個「盡量逼近」的過程，不是保證達標：把目標設得太激進，工具會努力壓，但畫質可能明顯劣化、出現色塊；它沒有「做不到就放棄」的保護機制，所以設定時最好預留一點緩衝，別直接把一支長片指定到極小的大小。對主流配置的電腦，處理幾百 MB 的錄屏、社群貼文素材或課程剪輯通常沒問題；一個順手的工作流程是先用〈Recordly〉或〈HitPaw Screen Recorder〉錄下畫面，丟進去指定一個目標大小，壓完直接寄出，整段流程都在本機走完。
誰該用、誰別勉強
一句話定位：它是「開源、可自架的 tools.video」，優勢在不上傳、能設目標大小、一份原始碼能搬回家自己架。臨時縮個人影片、錄屏、網站素材，它勝任；但若你手上有大量超大影片要批次壓製、或追求批次速度與穩定度，HandBrake 這類久經考驗的桌面工具在重度情境下仍然更可靠，兩者是分工而不是誰取代誰。若你真正的需求其實是剪輯而非縮檔，先看〈最佳影片剪輯軟體與工具〉會更對路。
