壓縮影片，全程不上傳

「不上傳」到底差在哪

網路上幾乎所有免費影片壓縮工具都是上傳型的。你把檔案交給一台自己控制不了的伺服器，它在別人的檔案後面排隊，處理完再讓你下載。這套模式能用，但代價不小：你的素材被複製到了別人的磁碟上，保留多久取決於隱私政策怎麼寫，而且一個 400 MB 的片子得先爬完你的上傳頻寬，才輪到開始處理。

這個工具反過來做。瀏覽器直接從磁碟讀取檔案，透過 WebCodecs API 把影格交給你裝置自己的視訊編碼器，再把新的 MP4 邊編碼邊寫回本機。全程沒有任何東西經過網路——你可以在壓縮時打開瀏覽器的網路面板確認，或者在頁面載入完之後斷網，照樣壓得出來。

由此帶來兩個實際差別。一是速度取決於你的硬體而不是上傳頻寬，所以短片幾秒就完事。二是沒有什麼需要限流的：沒有每日額度、不用排隊、不用註冊、沒有浮水印，因為背後沒有一台需要攤提成本的伺服器。

本機壓縮唯一做不到的，是在沒有視訊編碼器的瀏覽器裡執行。如果你的瀏覽器不受支援，上面的工具會直接說明，而不是偷偷退回上傳。

大檔案怎麼壓：為什麼這裡沒有容量上限

瀏覽器裡壓影片，翻車通常都翻在大檔案上，原因是記憶體。這類工具最直接的寫法是把壓好的影片先在記憶體裡湊成一整個，湊完了才交給你——於是一個工作需要的記憶體會隨著它自己產物的大小一起長。一段長錄影最後要的記憶體可能比機器能挪出來的還多，分頁就死在中途。這也是瀏覽器端壓縮工具通常都要掛一個最大檔案容量的原因。

這個工具不是這麼做的。壓好的每一段都在編碼完的那一刻就寫進瀏覽器的本機儲存空間，所以影片再長，記憶體佔用也是平的。這一點是實測過的：把一段 40 分鐘的 1080p 錄影壓成 500 MB，記憶體峰值 643 MB，從頭到尾一條直線；同一個工作改成在記憶體裡湊產物，峰值 1246 MB，而且壓到結束還在往上爬。這個差別就是這裡沒有容量上限的全部理由。

取代容量上限的，是一道不會讓你措手不及的檢查。開始編碼之前，工具會先估算產物有多大，再和瀏覽器實際可用的儲存空間比一比。放不下就當場告訴你，而不是讓你等四十分鐘才發現。半成品也不會留下：中途取消或者關掉分頁，寫了一半的檔案會被刪掉。

真正的天花板是你自己的可用磁碟空間，不是我們隨手定的一個數字。好幾 GB 的來源檔案沒問題——兩小時的影片是耐心問題，不是容量問題。

怎麼在瀏覽器裡壓縮影片

整個過程三步，不需要任何設定——預設的 720p 就是大多數人想要的。

1. 選一部影片，或者把它拖到上面的框裡。檔案在本機讀取，長度、解析度和容量會立刻顯示出來。
2. 選品質檔位。720p 看起來最接近原片；540p 是照通訊軟體的尺寸來的；360p 壓得最兇。目標解析度會在你確認前就顯示出來。
3. 按開始壓縮然後等。進度是真實的，不是估算的。完成後能看到前後容量對比，按下載儲存新檔案。

壓縮是單向的——丟掉的細節找不回來。在你看過壓縮後的效果並滿意之前，先留著原始檔。

該選哪一檔

每一檔都會把影片的短邊縮到一個目標值，並限制平均位元率。之所以按短邊而不是寬度算，是為了讓手機拍的直式影片和相機拍的橫式影片得到同樣的處理。

任何情況下都不會放大。如果你把一部 720p 的影片丟進 720p 檔，解析度會原樣保留，只有位元率變化——這一點值得知道，因為這種情況省下的空間會比 4K 來源少得多。

這三檔和這三個位元率與 Photo Slim 在 iPhone 上用的完全一致，所以同一個片子在這裡壓和在 App 裡壓，結果是一樣的。

怎麼把影片壓到 10 MB、25 MB 或 100 MB

有時候要的不是「小一點」，而是一個數字：上傳表單超過 25 MB 就不收，聊天軟體卡在 10 MB，某個入口網站的上限是 100 MB。把工具從品質檔位切到目標容量，你交給它的就是這個數字。它用預算除以影片長度得到位元率，扣掉音訊要佔的那一份，再挑一檔這個位元率撐得住的解析度——於是 720p、540p 還是 360p 不用你反覆試，它替你決定。

它刻意瞄得比目標略低，而不是正好壓到，因為壓出 25.4 MB 和壓出 60 MB 一樣會被拒。有兩條邊界值得先知道。音訊軌是原樣複製的，它在預算裡佔掉固定的一塊，任何品質設定都搶不回來。另外，影片長到一定程度，小目標就不再是品質問題而是根本做不到——四十分鐘的錄影不可能變成一個還能看的 10 MB 檔案。真遇到這種情況，工具會在你開始之前就說清楚，而不是花掉你的時間去壓出一坨馬賽克。

因為瞄的是「低於目標」而不是「等於目標」，無論對方按 1000 還是 1024 千位元組算一 MB，結果都能過線。

到底能壓小多少

這幾乎完全取決於來源檔案是什麼，任何承諾固定百分比的工具都是在猜。省下的空間來自兩處：降解析度和降位元率。如果你的來源在這兩項上都遠高於目標，縮減會非常可觀；如果本來就接近，能拿走的就不多了。

三個實測數字能把範圍說清楚。一段 9 秒、96 Mbps 的 4K 片子，在 720p 檔下從 105 MB 壓到 2 MB——不到原來的 2%，因為它的來源位元率對這個長度來說高得離譜。一段 121 秒的 1080p 影片從 101 MB 壓到 25 MB，約四分之一。而一段本身就是 720p 的 150 秒片子只從 95 MB 壓到 37 MB，約 39%，因為解析度根本降不下去。

規律很一致：高位元率的手機原片、螢幕錄影、以及任何 4K 素材，壓縮效果都極其明顯。而已經被壓過一輪的影片——比如從通訊軟體下載的片子——能再擠出來的很少，再壓一次主要是在損失畫質而不是省容量。

瀏覽器支援情況

這個工具需要 WebCodecs API 和一個可用的 H.264 視訊編碼器。目前版本的 Chrome、Edge 及其他 Chromium 核心瀏覽器，以及 Safari 18 以上版本都具備這個組合。Firefox 目前還沒有開放 WebCodecs 視訊編碼器，所以工具會偵測出來並告訴你，而不是壓到一半才失敗。

能力偵測在頁面載入時就完成，不是等你按按鈕才做，所以在選檔案之前你就會知道結果。

開始前值得知道的限制

這是個單檔案工具，邊界在哪就說在哪。事先講清楚，比壓到一半才發現有用得多。

1. 一次一個檔案。沒有批次佇列——要處理整個相簿，App 才是對的工具。
2. 沒有固定的容量上限，但有一道儲存空間檢查。天花板是你自己的可用磁碟空間，而且在開始編碼前就測，不會讓你壓到一半才發現。
3. 目標容量是盡力達成，不是保證。選 10、25 或 100 MB，位元率會從這個數字反推出來並刻意瞄低一點——但音訊原樣複製，在預算裡佔掉固定的一塊；影片長到一定程度，小目標在任何品質下都塞不進去。這一點會在你開始之前告訴你，而不是壓完才說。
4. 音訊是直接複製的，不重新編碼。原聲軌會逐位保留，包括 5.1 環繞聲——這也意味著音訊對容量縮減沒有任何貢獻。
5. 輸出固定是 MP4（預設 H.264，也可以開 HEVC）。這裡沒有格式轉換、匯出 GIF、剪輯或加浮水印。
6. 很長的影片仍然要等一會兒。在有硬體編碼的桌機上我們實測是十到十七倍於實時——10 分鐘的影片約一分鐘出結果——手機上會慢得多。

這裡做的任何操作都不會動你磁碟上的原始檔。壓縮後的是一個單獨下載的副本，要不要刪原檔永遠是你自己明確的決定。

常見問題