Nothing about processing media locally requires a server. We built a full media toolkit — conversion, trimming, denoising, vocal separation, subtitles, face redaction — where the entire pipeline executes inside the browser tab, and your files never leave the machine. This is the engineering tour: what each engine actually is, why it fits in a tab, and where the limits sit. No marketing, just the machinery.

Try the toolkit →

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

The engines, one by one

  • 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, 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 — and why local tools that skip those headers silently run single-threaded
  • 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 are built as streaming pipelines: the decoder hands over one frame, the effect draws onto it, the encoder writes it out, 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 a 32-bit address space, 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 download fetched 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.

The ten-second verification

  • Skeptical by default? Good — we would be too.
  • Open your browser's network monitor, drop a file into any tool claiming "local", and watch the transfer column. Ours stays at zero while the work happens. Every claim in this piece is checkable that way.

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's the wasm32 address space talking, not a 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, identical 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. A native Windows app with the same no-upload rule is what we built for 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 (file size, 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

Try the toolkit →

Everything above runs in your browser. Files never upload. Free to try.