Extract Audio From Video: MP3 in Your Browser
By Mark Fulton · 2026-08-26 · 11 min read
Open VidClip's video to MP3 tool, drop the video in, pick a bitrate, and save the MP3. The whole job runs inside the browser tab on your own processor, so there is no upload bar, no account, and no queue. Behind the scenes it runs one FFmpeg command that discards the video stream and encodes the audio with LAME at 128, 192 or 320 kbps. If you want a rule for the bitrate: 192 kbps for anything mixed, 128 kbps for pure speech you want small, 320 kbps only when the source is genuinely high quality music.
That is the two minute version. The rest of this is the part almost nobody writes down, which is that "extract audio" describes two very different operations, and picking the wrong one costs you either quality or convenience.
What audio is actually inside your video file?
An MP4 is not a format so much as a box. The .mp4 extension tells you about the container, and the container is a filing system: it holds one or more streams plus the timing information that keeps them in sync. MDN's guide to media containers is the clearest short explanation of that split if you want the full picture.
Inside that box, the audio is almost never MP3. For files that came off a phone, a camera, a screen recorder, Zoom, or a YouTube download, the audio track is overwhelmingly likely to be AAC. That is the default pairing with H.264 video and it is what nearly every device encoder writes. A .mov from an iPhone is the same story. A .webm will usually hold Opus or Vorbis instead. MDN's audio codec guide has the full matrix of which codec turns up in which container.
This matters for one reason. AAC is a lossy codec. MP3 is a lossy codec. They are not the same lossy codec, and there is no way to translate one into the other directly. To make an MP3, the AAC has to be decoded back to raw samples and then re-encoded by an MP3 encoder, which throws away a second, different set of information. Audio people call that generational loss, and it is the reason "extract audio" and "convert to MP3" are not synonyms.
None of which means you should panic. Read on, because the size of the loss is much smaller than the internet implies.
Should you copy the stream or convert to MP3?
There are two honest paths, and the right one depends entirely on what plays the file at the other end.
Copy the stream out untouched. The audio already exists as a finished, encoded track. You can lift it out of the container and drop it into a new one without any encoder running at all. Nothing is decoded, nothing is re-encoded, nothing is lost, and it finishes almost instantly because the work is a file copy plus a new set of headers. On a desktop FFmpeg install that is -vn -c:a copy, and the FFmpeg documentation on stream copy mode covers exactly what the flag does. You get an .m4a file holding the original AAC, bit for bit identical to what was in the video.
The catch is compatibility. An .m4a is fine in Apple Music, VLC, most modern podcast apps, phones, and browsers. It is not universally fine. Old car stereos, some cheap MP3 players, certain DAWs, and a surprising number of upload forms want a file whose name ends in .mp3 and will refuse anything else.
Re-encode to MP3. You accept one generation of loss and you get the format that plays everywhere and has done since 1998. This is the path VidClip's browser tool takes, and it is worth being precise about it: the tool always writes MP3. It does not offer a stream copy option. The command it builds drops the video stream entirely and hands the audio to LAME at whichever of the three bitrates you chose. So if you use the page, you are on the re-encode path by definition.
The practical decision is short. If the file is going into a podcast host, a phone, a car, or anywhere you cannot personally test first, take the MP3. If it is going into an editor, an archive, or your own library, and you know the player is modern, copy the stream and keep the original bits. The moment you are re-encoding anyway, stop worrying about the generation loss and start worrying about the bitrate, which is the setting that actually decides how it sounds.
What bitrate does speech need vs music?
Bitrate is how many bits per second the encoder is allowed to spend. More bits means a closer approximation of the original and a bigger file, in a completely linear relationship. Three choices are on offer, and each has a real use.
128 kbps for speech. A voice is a narrow, predictable signal. One person talking into a microphone does not stress an MP3 encoder in any interesting way. Lectures, interviews, webinars, voice memos, meeting recordings: 128 kbps is genuinely enough, and the file is small enough to sync to a phone without thinking about it.
192 kbps as the default. This is what the tool ships selected, and it is the right lazy answer. It handles speech with room to spare, handles music that is not being scrutinised on good headphones, and handles the messy middle case of a video with talking, background music and some sound effects. When you do not know what the audio contains, this is the setting that will not embarrass you.
320 kbps when the source deserves it. The highest bitrate the MP3 format defines. It earns its size when the source audio is a proper music recording that was captured at high quality in the first place. It cannot rescue anything. The FFmpeg guide to MP3 encoding is worth reading on this point, because the LAME project's own position for decades has been that the very top of the bitrate range is rarely where the audible gains are.
Here is the part that makes the choice concrete. Take a 40 minute recording, which is 2,400 seconds. At a constant bitrate, the output size is not a mystery you have to measure. It is arithmetic:
size in bytes = bitrate in bits per second × duration in seconds ÷ 8
Run that for all three settings:
| Bitrate | Calculation | Output size |
|---|---|---|
| 128 kbps | 128,000 × 2,400 ÷ 8 | 38.4 MB |
| 192 kbps | 192,000 × 2,400 ÷ 8 | 57.6 MB |
| 320 kbps | 320,000 × 2,400 ÷ 8 | 96.0 MB |
To be exact about what those numbers are: that is the calculation, not a benchmark. I have not measured your file. Real output lands a little above these figures because of ID3 tags and per frame headers, and the same equation is the one behind the video compression arithmetic if you want the longer version of why file size is never really a surprise.
What the table shows is the shape of the trade. Going from 128 to 320 kbps costs you two and a half times the disk space. For a talking head recording that is 57.6 MB spent on nothing you can hear.
The listening test that settles it takes about ninety seconds. Export the same file at 128 and at 192. Find the busiest ten seconds in it, somewhere with cymbals, applause, room noise, or overlapping voices, because that is where a low bitrate falls apart first and never in the quiet parts. Play both, same volume, same headphones. If you cannot pick the 128 out, you never needed 192, and you certainly never needed 320.
How long does extraction take locally?
Since the processing happens on your machine, the honest answer is that it depends on your machine, and I am not going to quote you a number I did not measure on it. What I can tell you is what governs the time, which is more useful anyway.
Three things dominate. First, on the very first run the page downloads the FFmpeg WebAssembly core, which is roughly 11 MB. That is a one time cost and the browser caches it afterwards, so the second extraction starts immediately while the first one appears to stall. Second, VidClip runs the single threaded build of the core rather than the multi threaded one. The multi threaded build needs cross origin isolation headers that break other things on the site, so the trade was made deliberately: slower, but it works in every browser with no configuration. Third, the run has to decode the whole audio track and encode the whole thing again, so time scales with duration rather than with how interesting the content is.
The comparison that matters is not against a desktop FFmpeg install. It is against an upload based converter, where your time is your upload speed plus their queue plus your download speed, on a connection you do not control, for a file you have handed to a stranger. Local processing skips all three of those, which is usually why it wins on wall clock time even though the encoder itself is slower.
One limit to know: the free tier caps input files at 200 MB, and Pro removes that cap so the only ceiling is how much your browser will hold in memory. On watermarking, be clear about what the rule actually is. The corner watermark on the free tier applies to re-encoded video exports. An MP3 has no picture, so there is nowhere for a mark to go and audio output never carries one. Pro is $4/mo billed $24 every six months, or $79 once for life, and what it buys is the removed size cap, no watermark on video exports, compression that hits an exact target size, instant lossless trim and mute, contact sheets, and the AI settings advisor.
What do you do with a track that is too quiet?
This is the most common complaint after extraction and it is almost always misdiagnosed. Nothing about pulling the audio out of a video makes it quieter. If the MP3 is quiet, the track inside the video was quiet, and you are simply hearing it without the visual distraction for the first time.
Two different problems hide under "too quiet". If the whole thing is uniformly low, the fix is gain, and you can apply it in any audio editor in seconds. If the loud parts are fine and the quiet parts vanish, the problem is dynamic range, and raising the gain will just clip the peaks. That one needs normalisation or compression rather than a volume knob.
FFmpeg's answer to both is the loudnorm filter, documented in the FFmpeg filters reference, which implements broadcast loudness normalisation and targets a consistent perceived level rather than a peak. Audacity's Loudness Normalisation does the same job with a graphical interface if you would rather see the waveform.
Being straight about the tool: VidClip's MP3 export does not apply gain or normalisation. It extracts and encodes, nothing more. If your track needs levelling, extract here and then run the result through an audio editor. Adding a bad automatic gain stage to an extraction tool would quietly damage files that did not need it, which is a worse default than doing one job properly.
If what you actually want is the words rather than the audio, VidClip's /transcribe tool is the Pro path, and it comes with one honest caveat that applies to no other tool on the site. Transcribe uploads. The audio is stripped and downsampled in your browser first, to mono at 16 kHz and 32 kbps, so no video and no full quality audio ever leaves the machine. But that compact speech file is then sent to a speech recognition service, and there is a per file consent checkbox you have to tick before it will run. Every other tool on VidClip stays local. That one does not, and it says so.
Frequently asked questions
Does extracting audio reduce quality?
It depends which of the two operations you ran. Copying the stream out of the container does not touch the audio at all, so the answer there is no, in the strictest possible sense. Converting to MP3 does reduce quality, because the original AAC has to be decoded and re-encoded, and both codecs are lossy. In practice, at 192 kbps from a normal video source, the difference is inaudible on ordinary equipment. The loss is real and it is also not something you will hear.
What bitrate should I use for a podcast?
128 kbps mono or stereo is the standard answer for spoken word, and it is the setting most podcast hosts will happily accept. Speech simply does not contain the frequency complexity that justifies more bits. If your show has music beds, stings, or field recordings mixed in, step up to 192 kbps. Going to 320 kbps for a talking podcast roughly triples your hosting bandwidth in exchange for a difference no listener has ever reported.
Can I get audio out of a video on my phone?
Yes. VidClip runs in a mobile browser the same way it runs on a desktop, because WebAssembly is supported across current mobile browsers. Two realistic caveats. Phones have less memory to spare, so a very large file is more likely to hit the wall on a phone than on a laptop, and encoding will be slower on phone silicon. For a lecture or an interview it works fine. For a multi gigabyte 4K recording, do it on a computer.
Is it legal to extract audio from a video?
For a video you created yourself, or one that is public domain or openly licensed, there is nothing to worry about. For copyrighted material, format shifting sits in genuinely unsettled territory that varies by country and by what you do next, and personal use is treated very differently from redistribution. The US Copyright Office's overview of fair use explains the four factor test courts actually apply, which is a better starting point than any blanket rule you will read online. This is general information and not legal advice. If you are extracting audio to publish it, the question to answer is whether you have the rights to the underlying recording, and that question has nothing to do with which tool you used.
Pull the audio out here
No upload, no account, no queue. Drop the video into the video to MP3 tool, pick 128, 192 or 320 kbps, and save the file. If what you actually wanted was the video without its soundtrack rather than the soundtrack without its video, mute video is the other half of the same job.