若要在本機壓縮影片檔案大小，請挑選一個瀏覽器可解碼的來源檔案，檔案大小上限為 500 MiB、長度上限為五分鐘，或解析度上限為 3840 × 2160 像素，從三種 WebM 重新編碼預設值（Small、Balanced 或 Quality）中選擇一種，然後讓瀏覽器內部的管線在即時播放的同時轉檔。原始位元組永遠不會離開您的裝置；此工具會透過瀏覽器的本機檔案 API 讀取檔案，根據所選的預設值重新編碼，並在您儲存之前顯示實際的輸出尺寸以及來源檔案與結果之間的位元組差異。這種方式的優點是快速、私密且可預測，因為同一個預設值在每次執行時都會產生相近的壓縮比。
大多數人會接觸到這項任務，通常出於以下三種原因之一：電子郵件附件無法上傳 1.4 GB 的螢幕錄影、手機相簿裡塞滿了比實際播放螢幕還要清晰的 4K 影片，或是簡報檔案已達檔案分享上限。在這三種情況下，根本問題其實相同 —— 來源編解碼器是為了封存品質而選擇的，而非為了分享。重新編碼會犧牲少量細節來換取更小的容器，而 WebM 之所以通常是合適的輸出格式，是因為 VP9 受到廣泛支援、能在所有現代瀏覽器中播放，並且在不同作業系統之間都能提供一致的結果。
為什麼檔案一開始就這麼大
在決定如何縮減影片大小之前，先了解是什麼讓它變大會有所幫助。現代智慧型手機能以約 400 MB 的大小錄製一分鐘的 4K 影片，因為相機會以完整解析度擷取每一幀、套用中等程度的幀內壓縮，並將結果儲存在包含中繼資料、音軌和動作向量的容器中。乘上您錄製的影片分鐘數後，一捲度假影片很快就會突破 5 GB 的大關，卻不會讓人覺得任何單一影片特別長。
幾乎所有膨脹的影片檔案都是由三個變數所主導：每一幀的解析度、每秒的幀數，以及編碼器每秒可花費的位元率。調降這三個數值中的任何一個，都會對最終檔案大小產生顯著影響，而這正是重新編碼所控制的範疇。一個 1080p 的幀只包含 4K 幀四分之一的像素數，因此在動到任何品質設定之前，光是降低解析度就能將檔案縮小 60% 到 75%。
目的端的用途也很重要。以 1280 × 720 算圖的簡報，無論來源多麼乾淨，都無法呈現 4K 母帶的額外細節。儲存封存和剪輯時間軸能受益於較高的位元率，因為它們能承受多次重新編碼；但是一次性的訊息應用程式分享則不需要。
三種預設值的實際作用
Video Compressor 提供了三種預設檔案設定，而不是一整排令人困惑的位元率滑桿，因為當選項只剩三個時，品質與大小之間的關聯會更容易理解。每個預設值都對應到一個目標位元率範圍和目標解析度上限，因此無論您餵入哪種來源檔案，輸出結果都能保持可預測。
| 預設值 | 目標 | 常見使用情境 |
|---|---|---|
| Small | 最小的位元組數；可接受細節流失 | 電子郵件附件、有上傳限制的聊天應用程式、預覽片段 |
| Balanced | 明顯縮小且幾乎看不出差異 | 社群媒體貼文、內部展示、專案作品集 |
| Quality | 適度縮小，接近原始保真度 | 封存副本、客戶交付檔案、第二代備份 |
選擇預設值本質上是在決定您願意犧牲多少細節。試算表的螢幕錄影對於積極壓縮的耐受度，遠比夕陽下的空拍畫面要好，因為平坦的區域和文字能在位元率削減後保持完整，而漸層和顆粒則無法。當目的端是聊天視窗時選擇 Small；當目的端是大多數觀眾以正常尺寸觀看的螢幕時選擇 Balanced；當目的端將被投影、放大或重新剪輯時選擇 Quality。
每種預設值在實際影片上的表現
同一個預設值會依來源素材的不同而產生明顯不同的結果，建立一個簡單的心智模型可以避免在長時間編碼後感到失望。高壓縮性的影片 —— 例如對著單純背景說話的半身畫面、簡報錄影、靜態的產品鏡頭 —— 對於每一種預設值都能輕鬆處理，因為畫面中大部分區域都是單一色彩。帶有動態模糊、底片顆粒或手持晃動的電影感畫面，則會對積極的預設值十分嚴苛，因為編碼器必須花費位元來處理持續變動的細節。
一個實用的經驗法則是去想像觀眾的觀看情境。如果觀眾會以直式方向在開啟聊天面板的手機上觀看影片，那麼實際可觀看區域大約只有兩吋的螢幕，這個尺寸小到即使是 Small 預設值看起來也沒問題。如果觀眾會在會議室的牆壁上觀看投影，那麼 Quality 預設值會是更安全的選擇，因為每一個瑕疵都會被放大。
開始之前：請先確認這些來源限制
這款壓縮工具會拒絕需要花費過長時間重新編碼，或超出瀏覽器所能解碼範圍的輸入，因此在開始之前值得先確認您的檔案落在允許的範圍之內。
- 檔案大小：上限為 500 MiB。較大的檔案應先使用 Video Trimmer 進行剪輯，或分割成多個較短的段落。
- 長度：上限為五分鐘。較長的影片可以切割成數個段落，然後分別進行壓縮。
- 解析度：上限為 3840 × 2160 像素（4K UHD）。任何高於 4K 的影片應先使用 Video Resizer 進行縮放。
- 編解碼器：必須為瀏覽器可解碼的格式。MP4（H.264/AAC）、WebM（VP8/VP9、Opus）以及 MOV（H.264）在現代的 Chromium、Firefox 和 Safari 中皆可正常運作。
如果您的來源不符合上述任何一項檢查，工具會顯示具體原因，而且檔案不會開始重新編碼。在這種情況下，正確的做法是先使用配套工具 —— 剪輯長度、調整幀的大小，或只擷取您實際需要的段落 —— 然後再帶著符合規範的檔案回到壓縮工具。
逐步壓縮影片檔案
- 在目前的桌面瀏覽器中開啟 Video Compressor。此工具完全在您的裝置上執行，因此沒有帳號、上傳佇列或登入步驟。
- 點擊檔案選擇器，選擇一個符合 500 MiB／五分鐘／3840 × 2160 限制的影片，或將檔案拖曳到放置目標上。
- 在 Small、Balanced 和 Quality 之間做出決定。Small 適合電子郵件和聊天用途；Balanced 適合日常分享；Quality 適合接近原始保真度的需求。
- 開始壓縮。來源檔案會在頁面上即時播放，同時瀏覽器內部的編碼器平行產生 WebM 輸出。在工作完成之前，請保持分頁處於聚焦且可見的狀態。
- 閱讀壓縮後的摘要資訊。工具會回報實際的輸出尺寸以及來源檔案與結果之間的位元組差異，讓您在儲存之前能確認縮小的幅度屬實。
- 下載 WebM 檔案，然後在其最終用途（聊天用戶端、簡報、媒體播放器）上完整播放一次，再刪除原始檔案。完整的播放能捕捉到快速拖動時可能掩蓋的卡頓、音訊飄移或瑕疵。
「保持分頁開啟」的指示比聽起來更為重要。重新編碼是一項持續性的工作負載，當分頁被隱藏時，瀏覽器會對其進行節流或暫停，這可能讓原本兩分鐘的工作延長到二十分鐘。如果您必須切換分頁，請回到壓縮工具的分頁，並確認進度指示器仍在推進後再離開。
解讀壓縮前後的數字
工作完成後，工具會顯示兩個值得關注的數值：最終的輸出尺寸以及位元組的變化量。尺寸能告訴您預設值是否對畫面進行了縮放（例如，使用 Small 壓縮的 3840 × 2160 來源，通常會以 1920 × 1080 的尺寸回傳），這是位元組節省量最大的單一因素。位元組變化則會以 MB 或原始大小的百分比，顯示絕對的容量縮減幅度，讓您能判斷輸出檔案是否已小到足以符合其目的端需求。
一個實用的健全性檢查：如果您的來源是螢幕錄影，但位元組變化小於 30%，對電子郵件附件來說，預設值的積極程度可能不夠。如果您的來源是自然景觀影片，但使用 Balanced 預設值時位元組變化超過 80%，則可以預期會在天空中看到色彩斷階 —— 這時的訊號是改用 Quality 預設值重新執行。
在這三種輸出尺寸之間做選擇
雖然每個預設值都有目標上限，但實際的輸出尺寸會選擇與來源長寬比相符的解析度，因此畫面絕不會被拉伸或裁切。1920 × 1080 的來源在 Balanced 和 Quality 預設值下會維持 1920 × 1080；只有在 Small 預設值下，當編碼器判斷來源的細節超出目的端需求時，才會降為較低的解析度。直式錄製的 1080 × 1920 手機影片會維持 1080 × 1920，而不是被填補進 16:9 的畫面中，這正是為何直式影片的位元組變化通常會略小於相同品質的橫式影片。
如果您需要一個符合特定目的端的輸出尺寸 —— 例如，提供給較舊的媒體播放器使用的 1280 × 720 母帶 —— 請先使用 Video Resizer 調整檔案大小，然後以 Quality 預設值壓縮調整後的結果。這個兩步驟的流程能產生比單次壓縮更一致的輸出，並讓您在投入較慢的編碼之前，先檢查調整後的檔案。
當壓縮不是合適的工具時
有時候真正的問題不是大小，而是形狀，壓縮工具只能處理表面的症狀。一段您從來不會完整觀看的 20 分鐘演講應該被剪輯，而不是被壓縮。內嵌於 16:9 影片中的 4:3 半身訪談畫面，應該被裁切到真正的主體。一段以 9:16 拍攝、需要在方形 Instagram 版位中顯示的直式手機影片，應該使用保持長寬比的適配方式來調整大小，而不是以原始幀幅重新編碼。
Lizely 更廣泛的影片工具組涵蓋了這些相鄰任務，且全程無需上傳來源檔案，這也是重點所在：每一個步驟都在您的裝置上執行，您只有在對結果感到滿意時才會下載新檔案。剪輯工作流程處理裁切長度，裁切工作流程處理取景構圖，調整大小工作流程處理長寬比 —— 在訴諸壓縮之前，請先針對實際問題選用合適的工具。
Verify the Output Before Deleting the Original
The single biggest mistake people make with any local re-encoder is deleting the source before confirming the result plays cleanly end-to-end. Re-encoding can introduce stutter at scene cuts, drift between audio and video over long durations, or rare decoder incompatibilities in older media players. Watch the full WebM at its actual destination — whether that is a slide deck, a Slack thread, or a QuickTime window — before recycling the original file.
For longer clips or clips with heavy motion, it is also worth scrubbing a few seconds in from the start and a few seconds before the end. Codecs frequently place keyframes at regular intervals, and a glitch in the first or last segment usually means the rest of the file will misbehave for some players. If anything looks off, re-run the job on a higher preset or trim the problematic segment with the Video Trimmer first and compress the trimmed result.
Why Local Re-Encoding Beats Cloud Uploads for This Task
Cloud compressors ask you to upload the full file, wait for their servers to re-encode it, and download the result. That round trip can take longer than the re-encode itself, it costs the provider bandwidth they pass on through limits or ads, and it leaves a copy of your file on someone else's disk. Local re-encoding in the browser inverts the workflow: the source stays on your machine, the encoder runs at native speed on your CPU, and the only network traffic is the download of the smaller file you actually wanted in the first place.
For work-in-progress clips, unreleased screen recordings, and any video with sensitive content, the privacy argument alone is usually enough. For everything else, the speed argument wins — a five-minute 1080p clip re-encodes in roughly its own playback time on a recent laptop, which is faster than most upload links on a typical home connection.
Troubleshooting Common Outcomes
If the download link never appears, the most common cause is that the tab was backgrounded long enough for the browser to suspend the worker. Returning to the tab and starting a fresh job usually resolves it. If the output plays but the audio is missing, the source likely used a codec the browser could decode for video but not for audio; remuxing the source with a standard AAC track before compression restores sound. If the output is far smaller than expected and the picture looks blocky, the source resolution was probably higher than the destination needed and the Small preset downscaled aggressively, which is the intended behaviour rather than a bug.
When none of these apply, the next step is to trim the source down to a 30-second sample and run the compressor on the sample. A short test re-encodes in a few seconds and lets you confirm whether the preset, the browser, and the source codec are all agreeing with each other before you invest the full job.
For a deeper look, see Crop Video for Free Online with Pixel Accuracy.
For a deeper look, see Shrink Video Files Locally in Your Browser Without Quality Loss.
For a deeper look, see Send Large Videos by Email After Compressing Them Locally.