How We Run FFmpeg, Whisper and Face Detection Entirely on Your Device

2026-11-02 · Formavide

Nothing about processing media locally requires a server. Here is the actual machinery — WebAssembly FFmpeg, WebGPU inference, WebCodecs streaming — that lets an ordinary browser tab decode, enhance and re-encode audio and video while the file never leaves your machine.

Conversion, trimming, denoising, subtitles, face redaction — everything runs in your browser. Files never upload.

The short version

Our tools decode, analyze and re-encode audio and video with no upload step — not because a server signed off on it, but because the entire pipeline executes inside the browser tab, on your machine, using a handful of platform capabilities that quietly matured over the last few years. This is the honest tour: what each engine actually is, why it fits in a tab, and where the limits sit.

• Format conversion, trimming, audio extraction — FFmpeg, the same engine professionals use, compiled to WebAssembly and run multithreaded inside the tab.
• Watermarks, subtitle burning, face redaction — streaming pipelines built on WebCodecs: hardware-accelerated decode, one processed frame at a time, re-encode on the way out.
• Denoising — DeepFilterNet3, a speech-enhancement network, executed by ONNX Runtime Web on a worker thread.
• Vocal separation — Spleeter as ONNX, with the STFT/ISTFT spectral math implemented directly in the browser; a heavier 4-stem engine (Demucs) runs on WebGPU for desktop Chrome and Edge.
• Subtitles — Whisper via transformers.js, automatically GPU-accelerated through WebGPU when the browser offers it, WASM otherwise.
• Face detection — MediaPipe's face detector feeding coordinates into the same streaming pipeline.

Why this became possible at all

A browser used to be a document viewer; it is now a runtime with four capabilities that together close the gap with native software:

• WebAssembly — C/C++ codebases like FFmpeg compile to a sandboxed instruction format that runs within striking distance of native speed.
• Threads via SharedArrayBuffer — the browser's version of pthreads. It requires cross-origin isolation (COOP/COEP response headers), which is why the site sends them.
• WebCodecs — direct access to the browser's hardware video decoders and encoders, so a pipeline can decode, touch every frame, and re-encode without a general-purpose media framework in the middle.
• WebGPU — compute shaders in the tab. Speech and separation models stop being CPU-bound and start finishing in something like real time.

The trick that keeps memory flat: streaming

The naive approach — load the whole file into memory, process, save — collapses at feature-length inputs, because a browser tab gives you a finite address space, not a server's RAM pool. So the frame-by-frame features (watermarks, subtitle burning, face redaction) are built as streaming pipelines instead: the decoder hands over one frame, the effect draws onto it, the encoder writes it out, and none of it accumulates.

The consequence: a 2-hour video costs roughly the same memory as a 2-minute one in those tools. The limits that do remain — around 500 MB for tools that hold the whole file at once — are honest ceilings of that memory model, not marketing numbers dressed up as features.

Models travel so files don't have to

The AI features invert the usual data flow. In the upload model, the multi-hundred-megabyte video crosses the internet to reach a model on a server. Here, only the model travels — a tens-of-megabytes network downloaded once from our own CDN and cached by the browser — while the video sits on disk where it started. After the first use, the AI features run with no network involvement at all.

Skeptical by default? Good. Open your browser's network monitor, drop a file in, and watch the transfer column sit at zero while the work happens. Every claim in this piece is checkable that way in about ten seconds.

The honest limits

• Memory model — tools that hold the whole file at once cap around 500 MB–1.5 GB (the trimmer takes 1.5 GB); that is the ceiling of a 32-bit address space, not an artificial paywall.
• Mobile — phones get 3-minute caps. A phone tab has neither the RAM nor the thermal budget for hour-long work.
• GPU availability — WebGPU is desktop Chrome and Edge today; elsewhere the same models fall back to WASM, slower but identical in output.
• Files beyond a tab — no browser-sized tool handles a 20 GB raw capture; the local trick is cutting the section you need first, and a native Windows app with the same no-upload rule is in development for exactly that tier.

Quick answers

• Is it really FFmpeg? The genuine article, cross-compiled to WebAssembly — same demuxers, filters and encoders, sandboxed by the browser instead of an installer.
• Does any file content reach your servers? No. Only anonymous numeric usage metadata (like file size and duration) is recorded; content and filenames never leave the device.
• Does it work offline? After the first load, engines and models are cached by the browser — the processing itself needs no network.
• Why should I trust the "local" claim? Don't. Verify it — the network-monitor check above takes ten seconds and works on any tool that makes the claim, including ours.