How ffmpeg.wasm confines video processing to a browser tab
ffmpeg.wasm compiles the C ffmpeg project into a WebAssembly module that runs entirely inside a browser. This post explains what is actually downloaded (~30 MB), how SharedArrayBuffer and cross-origin isolation enable multi-threaded encoding, and why the WASM sandbox itself enforces the "media never leaves your device" guarantee.
What is inside the 30 MB download
The first time you open a tool backed by ffmpeg.wasm (video-compress, video-cut, audio-convert and others), the browser fetches roughly 30 MB. The payload splits into two main pieces. ffmpeg.js is a thin JavaScript wrapper responsible for spawning a Worker, exchanging messages, and managing ArrayBuffers. ffmpeg-core.wasm is the compiled WebAssembly module containing ffmpeg itself, including codecs for H.264, VP9, AAC, MP3, and more.
When multi-threading is enabled, the browser loads ffmpeg-core-mt.wasm instead. The mt (multi-threaded) variant uses SharedArrayBuffer so that multiple Web Workers can share a memory address space and parallelise encoding work. SharedArrayBuffer was temporarily removed from browsers after the Spectre disclosure and was later re-enabled only for pages that send both Cross-Origin Opener Policy (COOP: same-origin) and Cross-Origin Embedder Policy (COEP: require-corp) headers. nosend-tools.com serves both headers, so browsers that support them get the multi-threaded build. The older asm.js fallback is not available in current ffmpeg.wasm releases; a WASM-incapable browser will simply fail to start the tool.
How the WASM sandbox keeps media on-device
A WebAssembly module executes inside an isolated linear memory region managed by the browser. It has no direct access to the network stack, and its "file system" is a virtual layer with no mapping to real OS paths. Media data flows in as an ArrayBuffer written into WASM memory by the JavaScript host, and the result flows back as an ArrayBuffer. Unless the JavaScript calling code explicitly passes that buffer to a fetch, XMLHttpRequest, or WebSocket, the data never crosses the WASM boundary to reach a network endpoint.
On a NoSend Tools page, the DevTools Network tab will show the initial library downloads and nothing else after processing completes. This is not a policy promise; it is something you can verify directly by watching the tab stay idle during conversion. On the Content Security Policy side, pages running ffmpeg.wasm must include wasm-unsafe-eval in the script-src directive or the browser will block WASM module instantiation before execution even starts.
Mapping to the NoSend Tools audio and video toolkit
video-compress, video-cut, video-to-gif, audio-convert, audio-noise, and audio-cut all share the same ffmpeg-core.wasm binary. Each tool constructs the ffmpeg command-line arguments it needs and calls ffmpeg.exec() with them, for example ffmpeg.exec(["-i", "input.mp4", "-crf", "28", "output.mp4"]) for MP4 compression. The 30 MB core is fetched once per browser session; switching between tools within the same session reuses the cached module and restarts nearly instantly.
The initial load takes 10 to 20 seconds because the 30 MB WASM binary needs to be fetched, compiled, and instantiated by the browser's JIT. Subsequent visits are served from the HTTP cache. The end-to-end tests for these tools set test.setTimeout(180_000) specifically to accommodate a cold Worker start during CI runs where the cache is empty.
"No upload" as a structural property, not a policy
Upload-based converter services are built around transmitting files to a server for processing. A privacy policy promising "deleted after conversion" is a statement about operator intent, but it is not verifiable by the user after the file has already passed through CDN caches, WAF buffers, and access logs on the way to the server.
In-browser processing with ffmpeg.wasm is structurally different: the path by which data could be transmitted to an external party does not exist in the code. The SharedArrayBuffer and cross-origin isolation machinery was introduced for security hardening reasons unrelated to privacy; ffmpeg.wasm inherits fast multi-threaded execution as a side effect. The privacy property of nosend-tools.com audio and video tools is a consequence of the WebAssembly sandbox model, not a feature layered on top of it.