Guides ·

How In-Browser Video Encoding Works Without Uploading Your Audio

Most online video tools upload your file to a server, render it there, and send back a result. This visualizer does not. Every step, from reading the audio to writing the final MP4, runs inside your browser tab. This article explains how that works, what it means for privacy, and where its limits are.

The short version

  • Your audio file is read from your disk by the browser and stays in the tab’s memory.
  • The spectrum analysis, bar drawing, and video encoding all run on your computer.
  • The finished MP4 is saved to your disk directly, either as a download or by writing to a file you choose.
  • The page does download code (the page itself, fonts, and the MP4 library). It does not send your audio or video anywhere.

Step by step

1. Reading the file

When you drop a file onto the queue or pick it with the file dialog, the browser gives the page a reference to that file. Nothing is transferred. The page reads the bytes into memory only when it needs them: to play the track in the preview, and to decode it for analysis.

2. Decoding the audio

The page uses the Web Audio API’s decodeAudioData to turn the compressed file (MP3, M4A, WAV, and so on) into raw audio samples. This is the same decoder the browser uses to play audio on any web page, so any format your browser can play will work here.

3. Analyzing the spectrum

The decoded samples are mixed down to mono, then analyzed with a fast Fourier transform once for every video frame of the export. At 30 fps a three-minute song produces 5,400 spectra. Each spectrum is stored in compact form, one byte per frequency bin, so even long tracks fit comfortably in memory.

This happens once per track. After that, every slider change re-uses the stored spectra, which is why adjustments show up instantly in the preview. The guide on how bar visualizers split frequencies explains the analysis in detail.

4. Drawing frames

For each frame, the page converts the stored spectrum into bar heights using the current reaction settings, then draws the bars onto an off-screen canvas: black background, rounded bars in your chosen color and layout. The preview and the export use the same drawing code, so the exported video matches what you saw.

5. Encoding with WebCodecs

WebCodecs is a browser API that exposes the computer’s video and audio encoders to web pages. Before it existed, a web page that wanted to produce a video file had two options: record the screen in real time, or ship a full software encoder compiled to WebAssembly. Real-time recording is slow (a one-hour song takes one hour) and can drop frames. Software encoders are large and slow.

With WebCodecs, the page hands each finished canvas frame to a VideoEncoder configured for H.264, and the decoded audio to an AudioEncoder configured for AAC. The browser picks an encoder the platform provides, which may be a hardware encoder on the graphics chip or a software one, depending on the machine.

Each frame is given an explicit timestamp (frame number divided by fps), so the encoder does not care how fast frames arrive. The page draws and submits frames as fast as the machine can handle, and the status line reports the speed as a multiple of real time.

6. Building the MP4

Encoded video and audio come out of WebCodecs as raw packets. They still need to be packed into a file a video editor can open. The page uses an open-source JavaScript library, mediabunny, to write the packets into an MP4 container with an H.264 video track and an AAC audio track.

7. Saving

There are two paths:

  • Shorter exports are assembled in memory. When encoding finishes, the page creates a file from that memory and triggers a normal browser download.
  • Long exports (estimated over about 80 MB) use the File System Access API. Chrome asks you where to save the file before encoding starts, then the page writes the MP4 directly to that file as it encodes. This keeps memory use low for hour-long playlists.

In both cases the file goes from the tab to your disk, not to a server.

What this means for privacy

Because the audio never leaves your computer:

  • Unreleased tracks, client work, demo mixes, and songs you generated but have not published yet can be used without sending them to another service.
  • There is no upload time. A 200 MB WAV file starts analyzing as soon as you drop it.
  • There is no server-side copy to be deleted later, because none was made.
  • There is no account to create, and no watermark is added to the output, because no server touches the file.

You can check this yourself. Open Chrome’s DevTools (F12), switch to the Network tab, then load a track and run an export. You will see requests for the page, its fonts, and the library code, but no request carrying your audio or the finished video.

Limits and trade-offs

Running everything locally has costs as well as benefits.

Browser support. WebCodecs and the File System Access API are best supported in Chromium-based browsers such as Chrome and Edge. The page checks for WebCodecs when it loads and disables export if the browser lacks it. The preview still works.

AAC availability. The WebCodecs specification does not require browsers to support AAC encoding, and not every browser build includes it. When the native AAC encoder is missing, the page loads a fallback AAC encoder library and registers it with mediabunny, so the export can still include audio.

Memory. Analysis keeps the decoded audio and the stored spectra in memory, and in-memory exports hold the whole MP4 until it is saved. Very long playlists on a machine with little RAM can hit the browser’s memory limits. The disk-streaming path for long exports reduces this, and splitting a long playlist into parts avoids it.

Speed depends on your machine. A server farm can be faster than a laptop. In practice, encoding a simple black-background bar animation is light work, and most modern computers finish well faster than real time, but an older machine may take longer.

The tab must stay open. Closing or reloading the tab cancels the export. Some browsers slow down background tabs, so keep the tab visible during long exports.

Why build it this way

A bar visualizer is a good fit for the browser. The audio analysis is cheap, the frames are simple shapes on black, and the output is a standard MP4. Running it locally removes upload waits and file size limits, and you do not have to trust a server with your music.

Open the visualizer →