ffmpeg-webCLI

FFmpeg compiled to WebAssembly, running client-side

ffmpeg-webCLI is a video editor that runs FFmpeg inside a browser tab through ffmpeg.wasm, the WebAssembly port of FFmpeg. A Web Worker processes the file in memory and the result comes back as a download, so no server ever receives the video. The name undersells it: most of the work happens in a panel of more than 30 operations, and typing ffmpeg arguments is just one mode.

Whisper subtitles and filter stacks encoded once

• On-device captions: Whisper runs in the page through Transformers.js. The transcript comes out as editable SRT, then goes back in as a toggleable track (MP4 or MKV) or burned into the frames. You pick Tiny (39 MB), Base (140 MB) or Small (466 MB), and the model stays cached in IndexedDB.
• Stack mode: compatible filters such as crop, rotate, fade, denoise, speed and volume merge into one -vf/-af chain, so the video is encoded once. The full command is shown before it runs.
• Batch queue: one operation or a whole stack applies to every queued file, with per-file preview and a ZIP of the results. 25 operations work in batch; crop, reverse and raw mode are among those that don't.
• Raw FFmpeg: whatever you type lands between -i input and the output name, with an optional second input file and 13 one-click recipes (loudnorm, deshake, lossless remux...).
• Offline PWA: once the 31 MB ffmpeg core is cached, processing needs no network.

Sensitive footage and 9:16 social clips

• Editing medical video, legal recordings or journalistic source material, the cases the project's paper gives for keeping processing local.
• Preparing a clip for TikTok, Reels or Shorts with 9:16 padding and burned-in captions.
• Stripping GPS coordinates and camera model from a file before sharing it.
• Running a video class on whatever devices students bring, without waiting for IT to install software.

No hardware encoding, and a 2 GB memory ceiling

Encoding is software-only and slow. The v2.0.0 release notes say as much: no hardware acceleration, built for ad-hoc edits and short-form video rather than bulk transcoding. The benchmark published in the repository puts numbers on it. H.264 compression of a one-minute clip takes 325 s in Chrome against 13 s for native ffmpeg running the same command, and VP9 WebM export of that clip crashes with a memory error. The repository's paper.md, written in June, claimed a 2 to 4x slowdown.

Memory tops out at 2 GB, the WebAssembly heap limit. Reverse buffers the whole video in memory and is disabled in batch mode for that reason.

The project sets itself against upload-based converters. The README names CloudConvert, Kapwing, Ezgif and Otter, which all receive your file, and calls the tool the reference implementation of a "Web-CLI" architecture described in a paper by Tejaswi Gowda of Arizona State University. If you would rather run a converter on your own server, ConvertX, a self-hosted file converter takes that route.

Hosting it yourself takes two response headers. The README says ffmpeg.wasm relies on SharedArrayBuffer, which requires Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. The repository ships server.js to set them. The code is GPL-3.0, so distributing a modified version means publishing its source.

Last release on 23 June, last code change in September. v1.0 shipped on 9 June 2026 and v2.0.0 on 23 June; no release has followed. The last code addition, on 5 September, lets the URL hash carry an operation (#cmd=), and its JSON schema restricts that to five operations and calls it an MVP. A commit on 20 October 2026 moved the app to the ffmpeg.webcli.app domain. The repository has four issues and pull requests in total, all closed.