Your browser already has the codecs
Every current browser ships a hardware-accelerated media stack for playing video, and the WebCodecs API exposes it to web pages directly. That means decoding an MP4’s audio track and re-encoding it as MP3 can happen on your machine, at close to native speed, with no server and no multi-hundred-megabyte WebAssembly download.
These tools use that stack through mediabunny rather than shipping a full media framework. The practical result is that a long recording starts processing the moment you drop it in — there is no upload progress bar first, because there is no upload.
Recordings are usually confidential
Audio is often the most personal file people convert. A recorded interview may be under an ethics approval. A therapy session, a client call, a medical dictation or a family voice note is not something to hand to a free web service in exchange for an MP3. Because the work happens locally here, there is no third party in the chain at all — the recording is read from disk into the tab and the output goes straight back to your downloads folder.
File length is limited only by your device’s memory rather than by an upload cap, so a two-hour recording is handled the same way as a two-minute one.
Extracting, trimming and picking a bitrate
Pulling the audio out of a video is a decode-and-re-encode job, not a rename — an MP4 container holds a compressed audio stream that has to be read and written back out on its own. Trimming is different again: cutting a section out and exporting it produces a clean file rather than a player that merely skips part of one.
On bitrate, the useful rule is to match the source. Re-encoding a 128 kbps podcast at 320 kbps does not recover anything; it only makes the file bigger, because the detail was discarded when the original was made. For speech, 96–128 kbps is transparent enough that listeners will not hear the difference; for music, 192 kbps and up is worth the space.