Convert WAV to MP3 on Mac

One source file: 30.000 seconds, 44.1 kHz, 16-bit stereo, 5,292,078 bytes, an audio stream measuring 1,411,200 bits per second. Machine: Apple M2 Pro, macOS 27.0 (build 26A428), 26 September 2026. Bytes from stat -f%z, bitrates from ffprobe.

Two rows need reading twice. afconvert ships on every Mac and cannot write MP3 at all. And our own output is the same byte count as free ffmpeg at -q:a 2, because it is free ffmpeg at -q:a 2. More on that below, since pretending otherwise would be the easiest lie on this page.

Apple documents the route in the Music User Guide, and it has worked the same way since iTunes:

1. Choose Music → Settings, click Files, then Import Settings.
2. Set Import Using to MP3 Encoder. The Setting pop-up beside it is where the bitrate lives.
3. Select the files, then choose File → Convert → Create MP3 Version.

Apple states the outcome plainly: “The song in its original format and the newly converted song appear in your library.” Nothing is overwritten, so the worst case is two copies and some tidying.

WAV is the easy case for this route. A WAV file almost never carries tags or artwork, so the metadata arguments that dominate converting FLAC to MP3 simply do not arise. What you lose converting WAV to MP3 is audio, not information.

We have not published numbers for the Music app. Measuring it properly means importing a test corpus into a real library, and a figure we did not measure cleanly is worth less than admitting we did not measure it.

Constant bitrate spends the same number of bits on every second of audio. Variable bitrate spends bits where the audio is complicated and saves them where it is not. Average bitrate is the compromise: it varies locally but is steered toward a target.

The difference is invisible until you measure it on material that actually changes. Our first fixture was a spectrally uniform tone bed, and VBR had nothing to work with: every one-second window came out between 172 and 178 kbps. So we rebuilt it with a loud passage, a quiet low-passed passage, four seconds of digital silence, and a loud passage again. Same 5,292,078 bytes in, three encoders out:

VBR produced a file 24% smaller than CBR and it did it by dropping to 32 kbps through the silence rather than faithfully encoding nothing at 192 kbps. That is the entire argument, and it is why LAME’s own --longhelp output leads with a recommendation rather than a menu:

RECOMMENDED:
    lame -V2 input.wav output.mp3

Three things worth knowing that the folklore gets wrong. CBR is not perfectly constant: our 192 kbps file measured 191 to 196 kbps per second, because MP3 frames hold 1,152 samples and do not align to second boundaries, and because LAME uses a bit reservoir. ABR undershot its target on the uniform bed, delivering 182,729 bps against a request of 192,000. And ffmpeg with no flags gives you 128 kbps CBR, which LAME documents as its default: “CBR (constant bitrate, the default) options: -b set the bitrate in kbps, default 128 kbps.”

Pick CBR when something downstream demands a fixed rate, such as a streaming encoder or a hardware player with a fussy decoder. Pick VBR for everything else. If you want the full arithmetic behind what these numbers mean per minute and per hour, audio bitrate explained covers it.

This one:

ffmpeg -i input.wav -c:a libmp3lame -q:a 2 -id3v2_version 3 output.mp3

-q:a maps to LAME’s -V quality scale, documented as “quality setting for VBR. default n=4. 0=high quality,bigger files. 9=smaller files”. Measured on the uniform bed:

Note what 320 kbps buys: a file 84% larger than V2 for material V2 was already spending 238 kbps on at its busiest. 320 kbps CBR MP3 is the setting people choose when they want to feel safe, and it is almost always wasted bytes.

-id3v2_version 3 is there for one reason. ffmpeg writes ID3v2.4 by default, and a real population of older car stereos and cheap players ignore v2.4 frames completely, so your tags vanish on exactly the device you made the MP3 for.

A whole folder is a one-line loop, and the flags that matter for a folder of tagged files are covered in batch converting audio on a Mac:

mkdir -p mp3
for f in *.wav; do
  ffmpeg -i "$f" -c:a libmp3lame -q:a 2 -id3v2_version 3 "mp3/${f%.wav}.mp3"
done

Write into a separate directory. A loop that writes alongside its inputs will eventually eat its own output, and you will not notice until the second run.

No, and it will let you get quite far before telling you. afconvert -hf lists 'MPG3' = MPEG Layer 3 among its formats, which is what sends people down this path. Then:

$ afconvert -f MPG3 -d '.mp3' music30.wav out.mp3
Error: ExtAudioFileSetProperty ('cfmt') failed ('fmt?')

Exit status 1, no file written. macOS ships an MP3 decoder and no MP3 encoder, and afconvert is a front end to Core Audio’s codecs, so the format appears in the list as something it can read.

Everything adjacent works. afconvert -f m4af -d aac -b 192000 music30.wav out.m4a produced 740,790 bytes measuring 194,905 bps, using Apple’s own AAC encoder, with no Homebrew involved. If the real requirement is a smaller file that plays on Apple hardware rather than literally MP3, that is the shortest path on any Mac. Note the trade-off if you script it: as covered in converting M4A to MP3 on a Mac, afconvert writes no tags and no artwork at all.

The Mac-specific version of this problem is “Converting WAV to MP3 using LAME and Automator” on Ask Different, asked 22 August 2011, score 8 with 11,434 views and three answers as of 26 September 2026. Fifteen years later people still reach for Automator and LAME because the built-in command-line tool genuinely cannot do it.

Not a better encoder, and we can prove it against ourselves. Smol converted the same WAV to MP3 in 1,270 ms, 5,292,078 bytes down to 654,999, an 87.6% cut. That is the same byte count as ffmpeg -c:a libmp3lame -q:a 2, the same 174,417 bps, and the decoded audio hashes identically: MD5 28b40b35df3cbb559ee7654db98c2b98 from both files. You are not buying a different sound.

What you are buying is that the decision is already made. Its audio conversion targets are m4a, mp3, wav, flac and ogg; compression adds aac and opus, with bitrate settable from 16 to 512 kbps and sample rate from 8 to 192 kHz. One useful wrinkle we measured: the conversion path writes VBR and the compression path writes 192 kbps CBR, which you can confirm yourself on any MP3 with the header check in audio bitrate explained.

If the batch is something you run every week rather than once, Smol ships an MCP server, so Claude Code, Codex and Google Antigravity can drive it directly, each one click to enable in the AI access panel as of Smol 1.0.35. “Convert every WAV in this folder to MP3” becomes an instruction rather than a script you maintain. The tool surface and the guardrails are on the Smol MCP page. For a folder you touch twice a year, that is overkill.

One input limit to know before you plan around it: AIFF is rejected. Handed a file straight out of /System/Library/Sounds, Smol returns “This file couldn’t be processed. It may be corrupted or in an unsupported format.” Convert AIFF to WAV with afconvert first.

For converting WAV to MP3, most of the time. This is not modesty; it is what the measurements on this page say.

One file, or files already in Music: use Music. Free, installed, documented by Apple, and it handles the library bookkeeping that no command-line tool does. Buying software to convert one WAV is not a close call.

Comfortable in Terminal: use ffmpeg. One line, free, and it produced byte-for-byte the same MP3 we did. You also get the flags we do not expose, like -abr, and the ability to see exactly what you asked for.

Nothing installed and no Homebrew: use afconvert for AAC. It will not write MP3, but 740,790 bytes of 194 kbps AAC from Apple’s own encoder, on a machine you are not allowed to install anything on, is a real answer.

What is left is narrow and specific: a folder you process repeatedly, where audio sits alongside the images and PDFs you were already squeezing, and where you would rather not remember which four flags keep the output sane. If that is not your week, the $29 is better spent elsewhere and the commands above will outlive several Macs. If it is, Smol runs entirely on your machine with no upload.