Voice Recorder

How browser recording works

Two APIs do the work. The first asks the operating system for access to an input device and returns a live stream of audio; the browser mediates that request, which is why permission is a browser prompt rather than something the page controls. The second takes that stream and encodes it into a container, emitting chunks of compressed data as it goes. The page never sees raw samples unless it asks for them separately — the level meter here uses a third API, an analyser node, that reports frequency magnitudes without giving access to the audio itself. Assembling the chunks into a file at the end is the only step the page performs on the data, and it happens entirely in memory.

Why the container varies

There is no single audio format every browser can encode. Chrome, Firefox and Edge produce WebM containing Opus, a codec designed for speech and music at low bitrates and an excellent default. Safari produces MP4 containing AAC. A recorder that assumes one and labels every file accordingly produces broken downloads on the other, and the failure is confusing because the file looks fine until something tries to open it. The correct approach is to ask the browser which formats it supports, use the first that works, and name the output after whatever was actually used.

Releasing the device properly

Holding a microphone stream keeps the operating system indicator lit and, on some systems, prevents other applications from using the device. Dropping the JavaScript reference is not enough: the underlying tracks remain live until explicitly stopped, and garbage collection is not prompt or guaranteed. Every exit path has to stop them — pressing stop, an error mid-recording, and the user navigating away, which is the one most often forgotten because it does not involve any code the page runs deliberately. This tool releases the stream on component teardown as well as on the obvious paths, so leaving the page ends the recording rather than leaving it running invisibly.