ffmpeg-webCLI 把剪片搬進瀏覽器
ffmpeg-webCLI 用 ffmpeg.wasm 在瀏覽器本地剪片,不上傳檔案,支援 32+ 操作、批次處理和離線使用。

ffmpeg-webCLI 是一個在瀏覽器本地處理影片的剪輯工具,檔案不必上傳到伺服器。
ffmpeg-webCLI 這東西很直接。它把影片處理搬進瀏覽器,而且真的在本機跑。第一次載入時,會先抓一個約 31 MB 的 ffmpeg.wasm 核心,之後還能快取。
這不是玩具 demo。它支援 32+ 種操作,還有批次處理、離線模式、stack mode。講白了,它想把很多常見剪輯工作,塞進同一個網頁裡。
| 指標 | 數值 | 意義 |
|---|---|---|
| ffmpeg-core 下載量 | 約 31 MB | 第一次使用要先付出載入成本 |
| 支援操作數 | 32+ | 可處理多數常見剪輯需求 |
| GitHub stars | 717 | 代表開發者有興趣 |
| GitHub forks | 56 | 顯示有人開始拿去改 |
| Commits | 121 | 看得出來不是隨便丟上去 |
本機處理,改變的是信任模型
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。
不會寄垃圾信,隨時可取消。
ffmpeg-webCLI 最有意思的地方,不是介面。是它不把你的影片丟去遠端伺服器。對剪片的人、行銷人、老師,還有要處理私人素材的人,這差很多。

很多網頁工具都很方便,但你得先上傳檔案。那一步看起來沒什麼,實際上就是把資料交出去。這個專案直接砍掉這段流程。它的 README 也寫得很白話:沒有上傳,沒有伺服器端渲染,也沒有資料蒐集。
這種設計,和 CloudConvert、Kapwing、Clideo 很不一樣。那些工具要先把檔案送到雲端,才開始做事。ffmpeg-webCLI 則是先在你的裝置上算完再說。
“No uploads, no servers — all processing happens locally in your browser using WebAssembly.”
這句話不只是在講賣點。它其實是在定義產品。當瀏覽器能做運算,瀏覽器就不只是看網頁的地方,而是工作本身的一部分。
當然,代價也很明白。算力是你自己的。筆電通常撐得住,手機就別太勉強。第一次載入也比較重,這點很現實,不要幻想它跟純雲端工具一樣輕。
- 不需要上傳檔案,隱私壓力小很多
- 離線也能用,適合網路不穩的環境
- 本機算力越強,體驗越順
- 第一次載入較慢,但之後可快取
功能比你第一眼看到的多
乍看之下,ffmpeg-webCLI 像是個簡單轉檔器。實際上,它能做的事不少。GIF 製作、格式轉換、壓縮、裁切、濾鏡、自動字幕、抽音軌、嵌字幕、畫中畫,還有直接輸入 ffmpeg 指令,幾乎把常見需求都收進來了。
這種整合很實際。你不用為了 GIF 開一個網站,為了字幕再開另一個,為了格式轉換又去第三個工具。對很多人來說,工具切換本身就是浪費時間。尤其是要處理一串素材時,少切頁面就少出錯。
它支援的格式也很務實。影片有 MP4、WebM、MKV、MOV、AVI。音訊有 MP3、AAC、WAV、OGG、FLAC。圖片輸出則有 GIF、JPG、PNG。這些格式不是炫技,是每天真的會碰到的東西。
- 影片格式:MP4、WebM、MKV、MOV、AVI
- 音訊格式:MP3、AAC、WAV、OGG、FLAC
- 圖片輸出:GIF、JPG、PNG
- 進階功能:串接、混音、字幕嵌入、畫中畫
壓縮介面也有料。它直接給你 CRF 18 到 51,還有 ultrafast 到 veryslow 的編碼預設。這種控制感,就是 ffmpeg 使用者熟悉的那套,只是前面多了一層比較好懂的介面。
換句話說,它不是把 ffmpeg 稀釋掉,而是把常用參數包成按鈕。這點我覺得很重要,因為很多網頁工具都太怕把細節露給使用者看,最後變成只能做半套。
stack mode 才是最聰明的設計
這個專案最值得講的,是 stack mode。它讓你先把多個操作排好,再一次輸出。像裁切、灰階、轉 MP4,可以合成一輪處理,不用每一步都重新編碼。

這件事很有感。因為重複編碼不只慢,還可能讓畫質越來越爛。stack mode 的設計,就是在避免這種浪費。它先做 trim,再跑 filter chain,最後只輸出一次。
README 也把規則拆得很清楚。像 crop、resize、rotate、adjust、grayscale、fade、denoise、sharpen、blur、speed、pad、letterbox、volume 這些單輸入操作,可以疊在一起。可是 concatenate、side by side、picture in picture、mix audio、embed subtitles、logo overlay 這類多輸入操作,就留在單次模式。
- 單次輸出可減少重複編碼
- 批次模式能把同一組操作套到多檔案
- 每個檔案可預覽,也能整包打包成 ZIP
- Web Workers 讓介面不會卡死
這代表它不是亂拼功能。它真的有理解 ffmpeg 使用者怎麼工作。大多數人不想為了一個結果輸出六次。他們要的是一次排好,一次跑完,一次拿檔案。
還有一個細節很加分。它會顯示實際的 ffmpeg command。這讓使用者不是只按按鈕而已,還能反過來學工具。對開發者來說,這比黑盒子有價值得多。
批次模式讓瀏覽器沒那麼脆弱
批次處理通常是瀏覽器剪輯工具的弱點。記憶體不好管,進度也不好追。ffmpeg-webCLI 的做法算務實。它用佇列、逐檔狀態、順序處理,還會在批次模式啟用時,處理已載入檔案的情況。
它也沒有假裝所有操作都適合批次。像 reverse 這種吃記憶體的功能,就明講可能需要整段影片緩衝,還可能碰到 2 GB 上限。crop、overlay 這種依尺寸或多輸入的功能,也會限制在批次模式外。
如果拿來跟其他工具比,差異就很清楚。CloudConvert 先上傳再處理,ffmpeg-webCLI 則是本機處理。Kapwing 和 Clideo 功能很廣,但資料要先離開你的電腦。Adobe Express 介面更漂亮,但 ffmpeg-webCLI 給的是更直接的 ffmpeg 控制。
這裡也能看出它的定位。它不是要打贏所有雲端剪輯器。它是要在隱私、控制權、離線能力這幾件事上,做得比一般網頁工具更乾脆。
GitHub 數字也有點意思。717 個 stars、56 個 forks、121 個 commits。這不像一個只做三天的 side project,比較像有人真的在維護。
- CloudConvert 偏雲端流程
- Kapwing 偏模板和協作
- Clideo 偏快速線上轉檔
- ffmpeg.wasm 是本機運算底層
這也反映了瀏覽器軟體的變化
ffmpeg-webCLI 其實在提醒我們一件事。瀏覽器現在不只是顯示頁面的地方。WebAssembly、Web Workers、離線 PWA,這些東西加起來,已經能撐起不少實作型工具。
幾年前,你說在瀏覽器裡剪影片,很多人會覺得很卡。現在不一樣了。不是所有桌面軟體都該搬進瀏覽器,但有些工作確實適合這種模式。載入一次、本機處理、不存檔到伺服器,這流程很乾淨。
這種工具在台灣也很有用。像學校老師要處理課程影片、行銷人要改短片、接案者要處理客戶素材,都會在意檔案不要亂傳。對這些人來說,少一個上傳步驟,就少一個風險點。
如果這個專案繼續長大,我覺得下一步很明顯。它可以加更多常用預設,像短影音、字幕燒錄、社群平台尺寸。也可以補更清楚的效能提示,讓使用者知道自己的裝置能跑到哪裡。
更大的問題是,其他網頁工具會不會開始跟進這種 local-first 做法。因為一旦使用者習慣了資料留在本機,很多雲端流程就會顯得很拖。你如果今天要剪片,我會建議先試這種本機方案,再決定要不要交給雲端。
結論很簡單:先看你在意什麼
如果你在意的是模板、協作、雲端分享,ffmpeg-webCLI 不是最順手的那種工具。但如果你在意隱私、離線、可控性,它就很有吸引力。
我會把它當成一個很實用的方向樣本。它證明了瀏覽器可以做更多,而且不用把檔案先送出去。下一次你要處理影片時,先問自己一句:這個工作,真的需要上傳嗎?