ffmpeg-webCLI: A Browser Video Editor That Never Uploads Your Files

The problem ffmpeg-webCLI solves, and who feels it

Most browser video tools are thin front ends over a server. You pick a file, the file goes up, a worker on someone else's machine runs ffmpeg, and the result comes back. CloudConvert, Kapwing, Ezgif and Otter all work this way, as the README points out. That is fine for a public clip and bad for a client recording, a medical video, an unreleased product demo, or anything covered by an NDA.

ffmpeg-webCLI takes the opposite position. The README states that all processing happens locally in the browser through WebAssembly, with no uploads and no servers. The project is a reference implementation of an architecture its author calls Web-CLI, described in a paper titled The Web-CLI: Verifiable Privacy for Tools, Models, and Inference Engines in the Browser by Tejaswi Gowda of Arizona State University. The paper names four properties: fidelity, progressive disclosure, offline-first and zero egress.

The audience is narrow but real. Journalists handling source material. Engineers on a corporate laptop where they cannot install binaries. Anyone who wants a GIF from a private clip without creating an account. The trade is capability for locality: you get ffmpeg's filter graph, but you get it inside a browser tab with a memory ceiling.

How ffmpeg.wasm runs ffmpeg inside a tab

The mechanism is ffmpeg.wasm, a WebAssembly build of ffmpeg. The repository also ships a server.js file and a .serverc.json config, so the project can be served locally as a static app, but the processing path does not depend on that server for computation.

The README says background work uses Web Workers, which keeps the interface responsive while an encode runs. Operations are exposed as a fixed set of panels rather than a single text box: GIF maker, format converter, compression, trimming, resize, audio extraction, mute, speed change, rotate and flip, crop, thumbnail, reverse, fade, adjust, metadata stripping, subtitle embedding, concatenation, picture-in-picture and audio mixing. A raw ffmpeg command field is also available for anything the panels do not cover.

Several details show real ffmpeg knowledge rather than a wrapper. GIF creation uses two-pass palette generation. Compression exposes a CRF slider from 18 to 51 plus an encoding preset from ultrafast to veryslow, with a live size estimate. Speed change adjusts both the video PTS and the atempo filter chain, and chains multiple atempo stages when the multiplier falls outside the 0.5 to 2.0 range a single filter accepts, so pitch and sync survive. Trimming is applied on top of every other operation, which means you can extract a clip, compress it and convert it to GIF in one pass.

The thumbnail extractor is the most interesting workaround. The README states the frame is always extracted as PNG via ffmpeg's -frames:v 1, and JPEG output is produced afterwards in-browser through a canvas. The reason given is a crash, memory access out of bounds, in the WebAssembly core's MJPEG encoder. That is a real limitation of the underlying build, and the project routes around it instead of pretending it does not exist.

Installing the PWA and running a first compression

There is no package to install for normal use. The README points to the live app at https://tejaswigowda.com/ffmpeg-webCLI/, and the project is a progressive web app, so after the first load you can install it as a native app and it works offline. The README states it works completely offline after first use.

If you want to run it from the repository instead, the top level contains server.js and .serverc.json, which suggests a small static server is included. The README does not document the exact start command, so check server.js before assuming one. The shape is likely a plain Node script:

node server.js

What you should see is the same interface as the hosted app, served from your machine. Because ffmpeg.wasm is a large binary, the first load pulls the WebAssembly payload; after that the PWA cache takes over.

Once the app is open, the flow is the same for every operation. Pick a file, choose a panel, adjust settings, run. For a compression pass, the README describes a CRF slider and a preset selector, with a live size estimate that updates as you move them. A CRF of 18 is near-lossless and 51 is maximum compression. Lower CRF means a bigger file and better quality.

For anything the panels do not cover, the raw ffmpeg command field accepts your own arguments. That is the escape hatch, and it is also the honest admission that a fixed panel set will never cover every filter graph.

Where ffmpeg-webCLI breaks down

The reverse operation is the clearest limit, and the README is direct about it. Reverse uses ffmpeg's reverse and areverse filters, which buffer the entire video into memory before processing. Combined with re-encoding, that is memory-intensive. The README says reverse works in single mode and is not supported in batch mode, to avoid exhausting memory when processing multiple large files, with the stated risk of hitting the 2GB WebAssembly heap limit.

That 2GB ceiling is the constraint that shapes everything else. A browser tab cannot address the memory a desktop ffmpeg process can, and WebAssembly makes that explicit. Long recordings, 4K sources, or a batch of several large files will hit it. The README's batch mode has a graceful fallback, but a fallback is not the same as success.

Speed is the other trade. WebAssembly is not native code, and a browser tab competes with everything else on the machine. The README advertises a fast and responsive interface through Web Workers, which addresses responsiveness, not throughput. If you are transcoding a two-hour lecture, a desktop ffmpeg build is the right instrument and this is not.

There is also an operational gap. The README documents features thoroughly but says little about failure and recovery. It does not document rollback, and it does not describe what happens to a partially written output if the tab is closed mid-encode. For a tool aimed at careful, private work, that is worth knowing before you trust it with the only copy of a file.

ffmpeg-webCLI versus a desktop ffmpeg install

The obvious alternative is ffmpeg itself, installed locally. It is the same engine, it runs natively, it has no 2GB heap, and it handles multi-hour files without complaint. The difference in approach is packaging and access. ffmpeg-webCLI trades raw throughput for a zero-install, zero-upload interface with panels, previews and a batch queue. Desktop ffmpeg trades convenience for capability.

The second alternative is a cloud converter such as CloudConvert, Kapwing, Ezgif or Otter. The README names all four and makes the distinction plainly: they handle the same tasks, but every one uploads your file to a server. Some are free with ads, some charge. The difference is not features, it is where the bytes go. If your file is not sensitive, a cloud tool may well be faster, because the server has more memory and no tab to share.

A third option is the raw ffmpeg.wasm library without this interface. That gives you the same WebAssembly core and the same 2GB ceiling, but you write the command plumbing yourself. ffmpeg-webCLI's value is the panels, the batch queue, the PWA shell and the workarounds like the canvas-based JPEG thumbnail path. If you only need one operation in your own app, the library alone may be the smaller dependency.

Maintenance, licence and what to check before depending on it

The repository is not archived, and the last push was on 2026-09-06, which is recent. Two releases are listed: v1.0.0 on 2026-06-09 and v2.0.0 on 2026-06-23. That cadence suggests a project that is still being worked on rather than abandoned, though the release history is short and a single maintainer is a single point of failure. The README does not describe a support policy or a release schedule.

The licence is GPL-3.0. That matters if you plan to embed the code in a product, because the GPL carries copyleft obligations for derivative works. This is not legal advice; read the LICENSE file in the repository and talk to someone qualified if you intend to ship a modified version.

Upgrade cost is mostly the ffmpeg.wasm dependency. The README does not document a version pinning policy, so check how the WebAssembly core is referenced before you fork. The thumbnail workaround is a good example of why: it exists because of a specific crash in the MJPEG encoder, and a core upgrade could either fix that crash or change the behaviour the canvas path depends on. Verify the thumbnail path after any core bump.

One more thing to check: the README does not document how batch mode reports a partial failure beyond a graceful fallback. If you plan to run batches unattended, test that path with a deliberately broken file first.

Editorial conclusion

Adopt ffmpeg-webCLI if your clips are sensitive, you are on a machine where you cannot install ffmpeg, or you want a free GIF, trim, compress or audio-extract pass without handing the file to a server. Do not adopt it for long recordings, high-resolution batch jobs, or anything that needs the reverse filter across many files, because the WebAssembly heap is finite and reverse is disabled in batch mode. Before relying on it, install the PWA, run one real file through the operation you actually need, and check the output size and quality yourself. The GPL-3.0 licence also matters if you plan to fork the code into a product.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tejaswigowda/ffmpeg-webCLI on GitHub