웹 어셈블리를 사용한 브라우저 측 파일 변환

A few months ago, I needed to add file conversion to a web app — nothing fancy, just letting users drop in a file and get back a different format. My first instinct was “call an API, done.” But sending user files to a server means storage costs, privacy headaches, and a queue if traffic spikes. So I looked into doing it entirely client-side with WebAssembly. Here’s what I learned, including parts that don’t appear in the getting-started tutorials.

Why WASM for this at all

Most format conversion logic (codecs, container parsing, compression) is written in C/C++ or Rust, and that ecosystem is mature. Compiling it to WASM means you get near-native decode/encode speed running inside the browser tab with zero server round-trip. For many formats, this is genuinely fast enough for real-time use.
The most common building block here is a WASM build of FFmpeg (ffmpeg.wasm is the popular one). It gives you the same codecs FFmpeg supports natively, just running in a Web Worker.

Where it gets messy

Memory is the first wall you hit
WASM linear memory is capped, and large video files can blow past it fast. You either have to chunk the input, stream it, or accept that very large files won’t work in the browser. There’s no clean way around this — it’s a real ceiling, not just a config tweak.
Threading is half supported
SharedArrayBuffer, which multi-threaded WASM builds need, requires specific COOP/COEP response headers on your server. Miss those headers and your app silently falls back to single-threaded mode — slower, with no error telling you why.
Bundle size matters more than people expect
A WASM FFmpeg build can be 20-30MB. That’s fine for a dedicated conversion tool, but it’s a rough addition to an app where conversion is a side feature—first load time takes a real hit.
Format coverage isn’t universal
Video and audio are well covered. Some proprietary image formats (certain camera RAW variants, some legacy document formats) either aren’t supported by open WASM libraries or need a much heavier custom build to handle correctly.

Where this actually shines

If your users mostly convert common formats (MP3/WAV/AAC audio, standard image types, and common video codecs) and file sizes are moderate, browser-side WASM conversion is a solid, privacy-friendly approach—files never leave the device. That’s actually the same trade-off behind tools.
If you’re building this yourself, budget real time for the memory and header issues above—they’re the parts that don’t show up until you’re testing with real-world files instead of a 2MB sample.