How do you get the audio out of a video file?
Short answer: open the video in the audio cutter. The page reads the sound track and ignores the picture. Drag the markers or type the start and end, pick WAV under Export format, and download. The video is read inside your browser, not uploaded. To turn whole videos into MP3s, several at a time, use the Video to MP3 converter.
- Formats: 12 of our 17 test videos opened: MP4, MOV, M4V, MKV and WebM with AAC, Opus, Vorbis, MP3, FLAC or PCM sound. AVI, AC-3, E-AC-3 and ALAC sound, and a video with no sound track, were refused.
- Accuracy: from an MP4-family file with AAC sound, the WAV came out exactly as long as the video (1,323,000 samples for 30.000 s) and within 2 steps of 65,536 of FFmpeg's own decode.
- Size limit: the file, not the length, decides. A 2,145,386,496-byte file opened; one byte more was refused. A 1080p video at 16 Mbit/s reaches that at about 17.5 minutes; 15 minutes (1.83 GB) opened in 12.5 s.
Pick WAV when you will edit the sound further: the sound in a video is already compressed, and MP3 export compresses it a second time (measured here). For a video over 2 GB, take the sound track out first with the FFmpeg command below; a 20-minute track came to 29.1 MB.
Why the picture does not matter, but the sound format does
A video file is a container holding separate streams: one for the picture, one or more for the sound. The cutter hands the whole file to the browser's audio decoder (decodeAudioData), which finds the first sound stream, decodes it and never touches the picture. That is why a MOV with an HEVC picture opened in our test even though HEVC picture support in Chrome depends on hardware: the picture was never decoded.
What does matter is the container and the sound codec. The Chromium project's Audio/Video codec support page (read 2026-10-03) lists MP4 (including MOV), Ogg, WebM, WAV and Matroska as containers, and FLAC, MP3, Opus, PCM and Vorbis as audio codecs, with AAC limited to Google Chrome. AVI, AC-3, E-AC-3 and ALAC are not on the list, and those were exactly the files that failed for us. Other browsers have their own lists; we tested only Chromium.
The whole file is also read into memory before decoding starts. A video is mostly picture data, so a short video can be a very large file, and that is what runs into the limit, not the minutes of sound.
How we tested
- Sound: 30 seconds (1:00 to 1:30) of Mozart's Symphony No. 40, first movement, played by the Musopen Symphony, public domain on Wikimedia Commons as a 48 kHz FLAC, used at 48 kHz and, for two files, converted to 44.1 kHz.
- Picture: FFmpeg's test pattern, 640 by 360, 30 frames per second, encoded as H.264, HEVC, VP9 or MPEG-4 Part 2.
- 17 videos made with FFmpeg 4.4.2, one per container and sound codec, plus a 5.1 file, a file with two sound tracks (music first, a 1 kHz tone second) and a file with no sound.
- Large files: 1080p H.264 at a constant 16 Mbit/s with 192 kbit/s AAC, 1 to 20 minutes, made by repeating a 60-second clip without re-encoding. For the exact limit we padded a 60-second video with zeros to a chosen byte count.
- Tool: the audio cutter on this site, run in Chromium 153 through Playwright 1.63 on a 4-core server with about 4.4 GB of free memory. Each video was opened, the whole sound track exported as WAV, and the WAV compared with the original music by cross-correlation, to the sample.
Results: which videos gave up their sound
| Container | Picture | Sound | Opened | Length shown | Music position in the WAV |
|---|---|---|---|---|---|
| MP4 | H.264 | AAC 48 kHz | yes | 0:30.000 | exact (0 samples) |
| MOV | HEVC | AAC 48 kHz | yes | 0:30.000 | exact |
| M4V | H.264 | AAC 44.1 kHz | yes | 0:30.000 | exact, within 2 steps of FFmpeg's decode |
| MKV | H.264 | AAC 48 kHz | yes | 0:30.037 | 21.3 ms late (941 samples) |
| WebM | VP9 | Opus | yes | 0:30.000 | exact |
| MKV | VP9 | Opus | yes | 0:30.000 | exact |
| MKV | H.264 | Vorbis | yes | 0:30.000 | exact |
| MKV | H.264 | FLAC | yes | 0:30.000 | exact |
| MOV | H.264 | PCM 16-bit | yes | 0:30.000 | exact |
| MP4 | H.264 | MP3 44.1 kHz | yes | 0:29.991 | 25.1 ms early (1,105 samples missing) |
| MP4 | H.264 | AAC 5.1 | yes, as stereo | 0:30.000 | exact, 7.66 dB quieter |
| MP4 | H.264 | two AAC tracks | yes, first track | 0:30.000 | exact |
| AVI | MPEG-4 Part 2 | MP3 | no | – | – |
| MKV | H.264 | AC-3 | no | – | – |
| MP4 | H.264 | E-AC-3 | no | – | – |
| MOV | H.264 | ALAC | no | – | – |
| MP4 | H.264 | none | no | – | – |
All five refused files got the same message, "Your browser couldn't decode this file. Try an MP3 or WAV.", within 0.13 s, so the message does not tell you whether the sound codec or the missing track is the problem. Every file that opened took under 0.8 s.
Tracks recorded at 48 kHz come out at 44.1 kHz, the rate the cutter works at. They still lined up with the original to the sample, with a correlation of 0.9972 (Opus) to 1.0000 (FLAC and PCM) against the original music, where 1 would be identical; the lower figures are the lossy codecs, not the conversion.
Three rows need a word:
- AAC in MKV, 21.3 ms late. AAC starts with 1,024 samples of encoder start-up. In our MP4, MOV and M4V files they were skipped; in this MKV they were not. FFmpeg 4.4.2 decoded the same file with the same 941-sample offset (1,024 samples at 48 kHz), so the extra lead-in is in the file, not added by the cutter.
- MP3 in MP4, 25.1 ms early. Here the opposite happened: FFmpeg decoded the music at the right place, but Chromium dropped the first 1,105 samples of music. 1,105 samples is the MP3 encoder and decoder delay we measured in Can you trim an MP3 to the exact millisecond?; it seems to be removed twice for this file. The first 25.1 ms of sound are gone, and the cut points land 25.1 ms early.
- 5.1, 7.66 dB quieter. The cutter folds 5.1 to stereo: centre to both sides, each rear speaker feed to its own side, all at 0.707, and each side divided by its total weight (1 + 0.707 + 0.707) so it cannot clip. Our test music was only in the front left and right, so it came out at 1/2.414 of its level, which is 7.66 dB. A real 5.1 mix with dialogue in the centre will come out differently.
Results: how big a video file can be
| Video length | File size | Opened | Time to open | Peak browser memory | 60 s WAV export |
|---|---|---|---|---|---|
| 1 min | 122 MB | yes | 0.9 s | 614 MB | 1.7 s |
| 5 min | 612 MB | yes | 5.5 s | 1,375 MB | 1.8 s |
| 10 min | 1.22 GB | yes | 8.0 s | 2,227 MB | 0.8 s |
| 15 min | 1.83 GB | yes | 12.5 s | 3,112 MB | 1.0 s |
| 20 min | 2.45 GB | no, refused in 0.17 s | – | – | – |
| 20 min, sound track only (M4A) | 29.1 MB | yes | 10.1 s | 1,797 MB | 1.1 s |
The 20-minute video was not too long; it was too big. The browser refused to read it at all and showed its own message: "The requested file could not be read, typically due to permission problems that have occurred after a reference to a file was acquired." Nothing about permissions was wrong.
To find the exact line, we padded a 60-second video with zeros. At 2,140,000,000 bytes it opened; at 2,147,483,647 it was refused. Halving the gap led to the edge: 2,145,386,496 bytes opened, 2,145,386,497 bytes did not. That number is 2 GiB minus 2 MiB, which is exactly the maximum allocation size set in Chromium's memory allocator, MaxAllocationSize in partition_alloc_public_constants.h (Chromium source, read 2026-10-03), whose comment says it is set below 2 GiB on purpose, as a security choice. The match is exact; we did not trace the file reader's code path to confirm it uses that allocator.
Below the limit, memory is the next wall. Peak memory at 15 minutes was about 1.4 GB more than the file size, so a device with less free memory than our 4.4 GB may run out on a file that is under 2 GB. We did not test phones, Firefox or Safari.
What to do
- Check the file size first. Under 2,145,386,496 bytes (shown as 2.15 GB, or 2.0 GB on systems that count in 1,024s), open it in the audio cutter. Over that, go to step 4.
- Mark the part you want. The cutter shows the sound track's length; drag the handles or type times to the millisecond. To keep the whole sound track, set the start to 0 and the end to the full length. For several clips, add one region per clip.
- Export WAV if you will edit, join or re-encode the sound later, or if timing against the picture matters. Export MP3 at 320 kbps only for a final file you want small.
- For files over the limit, take the sound track out without re-encoding it, then open the result in the cutter. With FFmpeg installed:
ffmpeg -i video.mp4 -vn -c:a copy sound.m4a.-vndrops the picture and-c:a copycopies the sound as it is. Our 2.45 GB video gave a 29.1 MB file that opened in 10.1 s. - If the video is refused with "couldn't decode", the sound is probably AC-3, E-AC-3 or ALAC, the container is AVI, or there is no sound track. Converting the sound to WAV first works:
ffmpeg -i video.mkv -vn sound.wav. Our refused AC-3 and ALAC videos, converted that way, both opened.
To put the sound of several videos into one file, add the videos to the audio joiner, which reads video sound tracks the same way.
Questions
Is this the same as separating vocals from a video?
No. This takes the whole sound track out of the video, voices, music and effects together. Splitting the voice from the music needs a separation tool, which this site does not have.
Does it work with videos from my phone?
We used test files, not phone recordings. An MP4 or MOV with AAC sound, including one with an HEVC picture, opened in our test, so a phone file with that combination should behave the same. Check the file size: a long high-resolution recording can pass 2 GB quickly.
Is the extracted sound lossless?
The WAV export holds the decoded sound track without further loss: for AAC at 44.1 kHz it matched FFmpeg's decode within 2 steps out of 65,536. It cannot be better than the compressed track in the video. A 48 kHz track is converted to 44.1 kHz, and MP3 export adds a second round of compression.