How Browser-Based Video Editing Works (FFmpeg.wasm Explained)

April 2026 · 8 min read · Technology

When you open TrimPrivate and drag in a video file, a full-featured video processing pipeline runs inside your browser tab — no upload, no server, no round trip to the cloud. Understanding how this works demystifies a technology that many assume is impossible without server infrastructure, and helps you make informed decisions about which tools to trust with sensitive footage.

The traditional model: server-side video processing

Almost every "online" video editor you have used works the same way: your browser uploads the file, the server processes it using server-installed software (usually FFmpeg or a commercial equivalent), and you download the result. The browser is just a user interface for a server-side operation. The computation happens on their hardware, not yours.

This model is simple to build, scales well for the service provider, and was the only practical approach until WebAssembly became widely supported around 2019-2020. It also means your video data leaves your device on every operation — an unavoidable consequence of the architecture.

WebAssembly: the key ingredient

WebAssembly (abbreviated Wasm) is a binary instruction format that modern browsers can execute at near-native speed. Unlike JavaScript, which is a scripting language designed for the web, WebAssembly is a compilation target — you can write code in C, C++, Rust, or Go and compile it to a .wasm binary that runs in the browser.

WebAssembly was designed from the start to be fast, safe, and portable. It runs in the same sandbox as JavaScript, so it cannot access the filesystem directly or make arbitrary network calls. It is supported in every major browser as of 2020: Chrome, Firefox, Safari, and Edge.

The critical property WebAssembly enables for video editing is this: you can take a large, complex native application — one that would normally require installation — and run it in a browser tab. FFmpeg is the most important example of this in the video processing space.

FFmpeg: the industry standard for video processing

FFmpeg is an open-source multimedia framework used by virtually every major video platform, broadcaster, and streaming service on the planet. YouTube, Netflix, Facebook, BBC — all use FFmpeg (or technology derived from it) to process video. It handles encoding, decoding, transcoding, muxing, demuxing, filtering, and streaming for hundreds of formats and codecs.

FFmpeg is written in C. It is fast, battle-tested, and extraordinarily capable. It can trim a 4K video, convert between formats, extract audio, change bitrate, apply filters, and much more — all from a command line or programmatic API.

Compiling FFmpeg to WebAssembly produces FFmpeg.wasm — a version of the same library that runs in the browser. The compilation is done using Emscripten, a toolchain that converts LLVM-compiled C/C++ code to WebAssembly. The result is a ~25 MB Wasm binary that, once loaded into a browser tab, provides essentially the full power of desktop FFmpeg.

How FFmpeg.wasm processes video without uploading

When you use TrimPrivate, here is what happens technically:

You select or drag a video file. The browser's File API reads the file into memory as an ArrayBuffer — a raw binary buffer. Your file never leaves your device at this step.
TrimPrivate writes the file to FFmpeg.wasm's virtual filesystem — a sandboxed in-memory file system that exists only within the browser tab. This is not your real filesystem; it is an isolated environment managed by WebAssembly.
FFmpeg.wasm is invoked with the appropriate arguments (trim start time, end time, output settings). It reads from the virtual filesystem, processes the video using the same codecs as desktop FFmpeg, and writes the output to the virtual filesystem.
TrimPrivate reads the output file from the virtual filesystem and creates a blob URL — a temporary URL that points to data in browser memory. You download from this URL, which writes the output directly to your real filesystem.
The tab's memory is cleared when you close it or refresh the page. No persistent copy of your video is stored anywhere except on your own device.

At no point does any video data traverse a network connection. The only network activity during a TrimPrivate session is loading the application itself (HTML, CSS, JS, and the FFmpeg.wasm binary) on first visit, and a small JSON ping at the end of processing for rate limiting purposes (no video data).

Stream copy vs. re-encoding

There are two ways to trim a video: stream copy and re-encoding. Understanding the difference explains why TrimPrivate can process large files in seconds.

Stream copy (the default in TrimPrivate) extracts the portion of the video you want without touching the encoded data. The video frames are copied directly from the input to the output without decoding or re-encoding. This is extremely fast — a 1 GB file can be trimmed in under 10 seconds — but the trim points must align with keyframe boundaries, and you cannot change any encoding parameters (resolution, bitrate, codec).

Re-encoding decodes every frame in the range you select, processes it, and re-encodes it with a new encoder (H.264 in TrimPrivate's case). This allows frame-accurate trim points, quality adjustment, and format changes — but it is significantly slower because decoding and encoding is computationally intensive. For a 500 MB file, re-encoding can take several minutes in the browser, versus seconds with stream copy.

For most use cases — trimming a clip to send to someone, cutting irrelevant sections, preparing an excerpt for a presentation — stream copy is the right choice. The output quality is identical to the input, and the operation is nearly instant.

SharedArrayBuffer and multi-threading

FFmpeg.wasm's multi-threaded version uses SharedArrayBuffer, a JavaScript API that allows multiple threads (Web Workers) to share the same memory. This enables FFmpeg.wasm to use multiple CPU cores for encoding, significantly improving performance for re-encoding tasks.

SharedArrayBuffer requires the page to be loaded in a secure context (HTTPS) with two specific HTTP headers: Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. TrimPrivate sets these headers on the main page, which is why multi-threaded FFmpeg.wasm works correctly at trimprivate.online.

Performance characteristics in practice

Browser-based video processing is slower than native desktop applications for re-encoding tasks, for two reasons. First, WebAssembly cannot access GPU hardware for video encoding — it uses your CPU only. Second, the browser sandbox adds a small overhead compared to running natively. On a modern mid-range laptop, expect roughly 0.5–2x realtime for H.264 encoding (processing a 60-second clip takes 30–120 seconds). For stream copy, performance is effectively I/O-bound and is near-instant for any clip length.

For the primary use case — trimming video to extract a specific segment — stream copy is the right mode, and performance is indistinguishable from a native desktop application.

Browser support and requirements

FFmpeg.wasm requires a modern browser with WebAssembly support. Chrome, Firefox, Edge, and Safari all support this as of their current versions. The multi-threaded version additionally requires SharedArrayBuffer support, which is available in Chrome and Firefox but may be limited in some Safari versions.

TrimPrivate works without an internet connection after the first visit, because the FFmpeg.wasm binary (approximately 25 MB) is cached by the browser's service worker or standard HTTP cache. This means you can process sensitive footage on an air-gapped machine after a single initial load.

FAQ

Does FFmpeg.wasm support all the same formats as desktop FFmpeg?
The core codec support is the same, but some features are limited — particularly hardware-accelerated encoding (H.264 via GPU), which requires native hardware access. FFmpeg.wasm uses software encoding only. Output quality is identical to software-encoded desktop FFmpeg, which is excellent.

How large a file can I process?
The limit is your device's available RAM. FFmpeg.wasm loads the file into browser memory during processing. As a rough guide, you need approximately 2–3× your file size in available RAM. A 500 MB file requires around 1–1.5 GB of available RAM. Most modern devices handle files up to 2 GB without issue.

Is the output quality the same as desktop FFmpeg?
Yes. FFmpeg.wasm uses the same codec libraries as desktop FFmpeg. A file processed at a given CRF setting in TrimPrivate will be identical to the same operation run in desktop FFmpeg.

See FFmpeg.wasm in action — for free

Trim any video in your browser · No upload · No account

Try TrimPrivate →