A HEIC photo becomes a JPG, a WAV file is created from an MP3, and none of it is uploaded. Sounds like magic, but it's solid engineering: WebAssembly. How browser-based conversion really works, where its limits are, and why it's a genuine win for privacy.

The classic model: upload, server, download

Traditionally, online converters work like this: you upload your file to someone else's server, a program like FFmpeg or ImageMagick does the work there, and you get the result back.

That works, but it has three problems. Your file leaves your device and sits, at least briefly, on third-party infrastructure. With large files you wait twice: once for the upload, once for the download. And the operator carries server and storage costs that grow with every user.

The modern model: everything stays in the browser

For a few years now there has been a way to move the actual computation entirely onto your device, into the browser tab itself. WebAssembly makes that possible.

WebAssembly (Wasm for short) is an official W3C standard and is supported by Chrome, Firefox, Edge and Safari. It's a compact binary format that programs written in languages like C, C++ or Rust can be compiled into, and it runs in the browser at near-native speed. The clever part: a C program grown over decades doesn't have to be rewritten for the browser; it's translated to Wasm once with a compiler toolchain like Emscripten.

On top of that comes the sandbox. Wasm code has no access to your operating system or file system. It only sees what the website deliberately hands it. In some respects that makes it safer than an installed desktop application.

Example ffmpeg.wasm: FFmpeg in the browser tab

The most impressive example is ffmpeg.wasm, the complete FFmpeg, compiled to WebAssembly. A Wasm module of about 31 MB contains the FFmpeg libraries (libavcodec, libavformat, libavfilter, libswscale, libswresample). The same command-line commands that otherwise run on a server work directly in the browser:

ffmpeg -i input.mp4 -c:v libvpx-vp9 output.webm

A conversion then looks like this:

File is chosen via drag & drop
        ↓
File API reads it into memory as an ArrayBuffer
        ↓
Wasm module receives the buffer in its virtual file system
        ↓
FFmpeg processes everything locally in the tab
        ↓
Result buffer comes back
        ↓
Browser offers it as a Blob download

The page's only network request is the one-time loading of the Wasm module. After that it's cached, and the actual file is never transferred.

For images it often runs even more lightweight via the browser's native Canvas API: load the image, draw it into a canvas, output it again as JPG/PNG/WebP. For special formats like HEIC a small Wasm module is added, for example a libheif port.

The stumbling block: COOP and COEP headers

There's a technical catch that trips up many developers. For multi-threaded processing, ffmpeg.wasm needs the SharedArrayBuffer, that is, shared memory between the main thread and web workers. For security reasons (keyword: Spectre), browsers only expose it in a "cross-origin isolated" context.

Concretely, the server has to send two headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Only then is the fast, multi-threaded mode available. There's also a single-threaded variant of the core that runs without these headers, just slower. SharedArrayBuffer itself is supported by Chrome (since 92), Firefox (since 79) and Safari (since 15.2), so in 2026 it's effectively available everywhere.

The honest limits

Browser conversion is great, but it's no cure-all:

  • Speed: WebAssembly runs slower than a native program, roughly 5 to 20 times depending on the codec and device. The multi-threaded core is about twice as fast as the single-threaded one, but doesn't fully close the gap.
  • Memory: The browser limits the working memory per tab. Very large files such as a long 4K video can hit this limit.
  • Codecs: Patent-encumbered formats are often missing from the standard build. HEVC or AV1 encoding are frequently absent; H.264 decoding, VP9 encoding and plain format conversion work without issues.

For exactly these reasons the pragmatic path is a hybrid one: what computes well locally, images above all, runs in the browser. What needs a lot of compute power or specialized libraries, such as some document conversions, sensibly stays server-side, but then with immediate deletion of the file.

Why this matters for privacy

The real gain isn't in the technology but in its consequence: if a file never leaves your device, it also can't be stored, logged or passed on anywhere. For photos with metadata, for confidential documents, for anything under GDPR considerations, that's a fundamental difference from the classic upload converter. There's no transmission for anyone to peek into, and no copy that gets "forgotten" somewhere.

This is exactly the principle wandlio is built on: image conversions run locally in your browser, documents server-side, and in both cases your file is always deleted.

Try it yourself

No account, no upload, no waiting for a server round trip.