A journalist sent me four hours of interviews as M4A files because her transcription service rejected them, and asked whether converting to MP3 at 320 kbps would "keep the quality high". It would not. The recordings were 64 kbps mono voice memos, and re-encoding them at 320 would have produced files five times larger holding exactly the same audio, plus a fresh layer of damage from the second encoder. What she needed was WAV, because the transcription service wanted PCM, and the file size did not matter for a thing she was uploading once and deleting. The conversion took a minute. The useful part was working out which direction the loss runs, and that is worth understanding before you convert anything.
TL;DR: M4A and MP3 are both lossy, so converting between them decodes audio that already has detail missing and compresses it again with a different model. There is no setting that avoids this. Two rules keep it small: never pick a bitrate above the source, because the extra bits describe the first encoder's artefacts rather than the recording, and keep the original as your master rather than the converted copy. If the destination is an editor, a transcription service or a speech model, convert to WAV instead and skip the second generation entirely. The audio converter on toolz.dev runs ffmpeg through WebAssembly in your own tab, so an interview or a voice memo never leaves the machine.
What is inside an .m4a file?
The extension names the container, not the audio, and that one distinction clears up most of the confusion around this format.
M4A is an MPEG-4 container holding a single audio track. What sits inside it is usually AAC, which is what an iPhone voice memo, a Mac screen recording, a QuickTime export and most Apple downloads produce. But the same container, with the same extension, can hold Apple Lossless instead, and those two files behave nothing alike: one has already thrown detail away, the other has not. An .m4a from iTunes Match is AAC. An .m4a ripped by Apple Music in lossless mode is ALAC and is roughly five times the size, which is how you tell them apart without a tool.
This matters because the right conversion depends on the codec, not the extension. An AAC file converted to MP3 loses a second generation. An ALAC file converted to MP3 loses its first. Converting either to WAV or FLAC loses nothing further, though neither can restore what AAC already discarded.
The same relationship between container and codec governs video, where it causes the much bigger misunderstanding covered in the remux guide: changing the wrapper is cheap, changing the compression is not.
Why does converting M4A to MP3 make it worse?
Because both formats work by discarding what a psychoacoustic model predicts you will not hear, and the second encoder cannot tell the difference between the recording and the first encoder's leftovers.
AAC and MP3 build different models. They disagree about which frequencies are masked by louder neighbours, they split the signal into different numbers of bands, and they handle sudden transients differently. So the detail AAC decided to keep is not the detail MP3 would have kept, and vice versa. When MP3 encodes the decoded output of an AAC file, it spends bits preserving artefacts that were never in the microphone's signal, and throws away some of what survived the first pass.
The damage shows up in a predictable order. Cymbals and hi-hats go first, turning into a sort of smeared hiss. Applause follows, because a room full of hands is close to noise and noise is the one thing these codecs cannot model. Then sibilance, the "s" sounds in speech, which develop a warble that is hard to unhear once you have noticed it.
None of this is an argument against converting. It is an argument for converting once, from the original, when something downstream genuinely needs a different format. M4A is not a worse file than MP3. At the same bitrate AAC generally sounds better, which means going from M4A to MP3 is a compatibility step that costs you a little quality, not an upgrade that gains you any.
Which bitrate should you pick?
Match the source or go slightly below it, and never above.
The reason is the one above. Bits above the source rate are spent describing artefacts, so a 128 kbps M4A re-encoded at 320 kbps MP3 is two and a half times the size for no audible gain. Going well below the source does the opposite and throws away a second helping of real detail. If you know the source bitrate, use it. If you do not, 192 kbps is a reasonable default for music and anything at or above 128 is fine for speech.
The ceiling is not a tool decision. MPEG-1 Layer III tops out at 320 kbps, which you can read off the bitrate index table in the MPEG audio frame header, and no encoder can exceed it regardless of what an interface offers.
Here is what each target costs per minute of stereo audio.
| Target | Per minute | Lossy? | What it is for |
|---|---|---|---|
| MP3 128 kbps | 0.96 MB | Yes | Speech, podcasts, anything going to a device that only reads MP3 |
| MP3 192 kbps | 1.44 MB | Yes | The default. Music you will listen to rather than master |
| MP3 320 kbps | 2.40 MB | Yes | Only when the source was at least this high |
| M4A (AAC) | Same as MP3 at the same rate | Yes | Apple devices, and better sounding than MP3 rate for rate |
| OGG (Vorbis) | Same again | Yes | Games, web audio, anywhere patent-free matters |
| FLAC | about 6 MB | No | Archiving a lossless source |
| WAV | 10.1 MB | No | Editors, transcription services, speech models |
The WAV figure is not an estimate. Uncompressed stereo PCM at 44.1 kHz and 16 bits is 44,100 x 2 channels x 2 bytes per second, which is 176,400 bytes a second and 10.1 MB a minute, every time, whatever the audio contains. Silence costs exactly as much as a symphony.
When should you convert to WAV or FLAC instead?
Whenever the destination is a machine rather than a pair of ears.
Audio editors, transcription services, forced-alignment tools and speech models all want PCM, and handing them a lossy file means they decode it first anyway. Converting to WAV yourself skips a second lossy generation entirely: the decode happens once, the result is exact, and nothing further is discarded. The file is large and that is fine for something you upload once.
FLAC is the archive answer rather than the working one. It compresses losslessly to roughly 60% of PCM on typical music, so the audio is recoverable bit for bit while the file is a third smaller. It is now formally specified in RFC 9639, after two decades as a de facto standard, and it carries a detail worth knowing: the STREAMINFO block holds an MD5 signature of the unencoded audio, so a decoder can prove its output matches the original sample for sample. No lossy format can offer that, and no lossy source can be rescued into it. Converting an MP3 to FLAC produces a larger file holding the same damaged audio, which is a common and entirely pointless operation.
# what the conversions amount to, if you have ffmpeg installed
#
# M4A to MP3, matching a 192 kbps source:
ffmpeg -i memo.m4a -vn -acodec libmp3lame -b:a 192k memo.mp3
# M4A to WAV for a transcription service (16-bit PCM, 44.1 kHz):
ffmpeg -i memo.m4a -vn -acodec pcm_s16le -ar 44100 memo.wav
# size arithmetic, which needs no tool:
# lossy MB per minute = kbps x 60 / 8 / 1000
# WAV MB per minute = 44100 x 2 x 2 x 60 / 1024 / 1024 = 10.1
Why is there a gap at the start of my MP3?
Because MP3 cannot represent an arbitrary number of samples, and the fix lives outside the audio data.
An MPEG-1 Layer III frame holds exactly 1152 samples. A file's length therefore rounds up to a frame boundary, and the encoder also needs a lead-in before it can produce valid output, so every MP3 carries a small amount of silence at the front and a little padding at the end that were not in the source. At 44.1 kHz that front gap is a few tens of milliseconds. Between tracks of an album recorded as one continuous performance, it is the difference between a live recording and a slideshow.
The format has no field for this. What players use instead is a header the encoder writes into the first frame recording the delay and the padding, so a player that reads it can trim both and a player that does not will not. AAC in an MP4 container has the length as part of the container structure, which is why M4A files are gapless by default and MP3 files are gapless only by convention.
For a single voice memo none of this matters. For converting an album, it is the reason the result sounds subtly wrong even though every individual track is fine.
Why did my conversion fail on a file with album art?
Because the artwork is stored as a video stream, and an encoder asked to write it into a format with nowhere to put it gives up.
An MP3 or M4A with embedded cover art has two streams: the audio, and a single still image that the container describes as video. Converting without saying otherwise, ffmpeg tries to carry that image into the output, and for targets like WAV the operation has no meaning and fails with an error that mentions a video codec on what is clearly an audio file.
The fix is one flag, -vn, which drops video streams entirely. The converter here passes it on every conversion, so the artwork is discarded and the audio converts. If you want the cover art preserved, convert to a format that carries it and re-attach it with a tag editor afterwards, because no converter will do both reliably.
Is OGG worth choosing?
For most people, no. For two specific cases, yes.
Vorbis in an Ogg container is, in Xiph's own words, a "fully open, non-proprietary, patent-and-royalty-free, general-purpose compressed audio format". That is the whole argument for it, and it is a real one if you are shipping audio inside a game, an application you distribute, or anything where codec licensing is a question somebody will eventually ask.
Against it: hardware support is patchy. Plenty of car stereos, older phones and cheap players read MP3 and nothing else, which is the reason MP3 remains the safe choice for a file going to a person rather than a program. Browser support is good and has been for years.
The sound is a wash. At the bitrates most people use, Vorbis and AAC are both better than MP3 and close to each other, and none of that survives a second generation anyway.
Does the audio leave my machine?
No, and for this category of file that is the point.
The conversion runs through ffmpeg compiled to WebAssembly inside the browser tab. The file is read from disk into page memory, converted there, and handed back as a download. Open the network panel in devtools during a conversion and nothing carries the audio.
Think about what people convert. Voice memos. Recorded interviews. Therapy notes. Customer calls. Lectures somebody recorded with permission that did not extend to a third party. The normal arrangement for a free online converter is that you upload all of that to a stranger's server in exchange for a download link, and the retention policy is whatever the footer says. Here no copy exists to retain.
The limits are the tab's rather than a plan's: 300 MB of source, which is about five hours of 128 kbps audio or half an hour of WAV. Past that a desktop encoder is the better tool, and the same logic as the video compressor applies, where the browser's memory rather than a paywall sets the ceiling.
What if the audio is inside a video?
Then this is the wrong tool, and the distinction is not pedantic.
Pulling the soundtrack out of an MP4 is a different operation from re-encoding an audio file: when the video's audio track is already AAC and you want an M4A, the stream can be copied straight out with no re-encoding and no loss at all. That is what the audio extractor does, and it is why it exists as a separate tool rather than a mode of this one.
The order that loses the least, if you need an MP3 from a video: extract first, check what codec came out, and only convert if the result is a format your destination refuses. Converting the video straight to MP3 in one step works, but it hides whether a lossy re-encode happened or not.
What about the other direction, MP3 to M4A?
Worth doing in one case and pointless in the rest.
The case where it helps: an Apple device or an app that only reads M4A, which still happens with older car integrations, some audiobook players, and anything that expects an AAC track in an MPEG-4 wrapper. Then it is the same compatibility step as going the other way, with the same cost.
The case where people reach for it and should not: hoping for a better-sounding file. AAC is a better codec than MP3, but that advantage applies when it encodes an original recording. Handed a decoded MP3, it encodes the MP3's artefacts faithfully, at a new bitrate, and the result is a second generation that sounds very slightly worse and takes up roughly the same space. No format upgrade can recover detail that is no longer in the samples.
The honest test is to ask what the file is for. If something refuses to play it, convert. If it plays fine and you are trying to improve it, the only real improvement is to find the original.
Can I convert a folder of files at once?
Not in the browser, and that is the boundary worth being clear about.
Each conversion loads the whole file into the tab and runs a single ffmpeg pass, so the tool handles one file at a time by design. For three voice memos that is faster than installing anything. For a music library it is the wrong tool entirely, and a shell loop over a local ffmpeg will finish while a browser is still on the second file.
# the batch version, once there are more than a handful
for f in *.m4a; do
ffmpeg -i "$f" -vn -acodec libmp3lame -b:a 192k "${f%.m4a}.mp3"
done
The dividing line in practice sits around ten files or half an hour of audio. Below it the browser wins on setup time, above it a local encoder wins on everything. The same trade-off governs the video compressor, where tab memory rather than a subscription tier sets the ceiling, and the video converter for the format side of the same problem.
