How we process audio in your browser: FFmpeg.wasm, Web Audio and local models

Most audio-tool sites upload your file to a server, process it and send the result back. We do almost everything in your browser. It's more private (your audio never leaves your device), cheaper to run and, done right, faster. Here's how it works inside.

Two engines for two jobs

• Web Audio API for listening: as you move a slider, the sound changes instantly. The file plays in an <audio> element routed through a node chain (filters, delays, convolution reverb, a pitch worklet).
• FFmpeg.wasm for export: FFmpeg compiled to WebAssembly decodes any format and encodes the result as MP3, WAV, FLAC, OGG or M4A. It runs in a Web Worker so the page never freezes.

What you hear is what you download

The risk of two engines is that preview and final file sound different. We solve it two ways. For effects, each Web Audio chain mimics the filters FFmpeg applies on export (same frequencies, slopes and reverb response). And for things generated in the browser — instruments, drum machines, the voice changer, the Lab — we render the same chain in an OfflineAudioContext and FFmpeg only encodes the result.

On-device AI models

Vocal separation (Demucs), transcription (Whisper) and text-to-speech (Kokoro) use models downloaded once from public servers and run with ONNX Runtime Web, on WebGPU when available and WebAssembly otherwise. The first run is slower; afterwards the files stay in the browser cache.

Lazy loading and memory

• Nothing loads until needed: the FFmpeg core (about 30 MB) and models only download when you press a tool button that uses them.
• One worker per job: each process lives in its own worker; cancelling terminates it and frees the memory at once.
• Honest limits: 100 MB and 10 minutes per file. Beyond that, a mobile browser can run out of memory.

The exception: YouTube

Browsers can't read YouTube videos directly, so YouTube to MP3 asks our server for the original audio track. The MP3 conversion still runs on your device.