Convert between MP3, WAV, OGG, AAC, M4A and FLAC with a bitrate, sample rate, channel count and bit depth that all reach the encoder, and a panel that reports what was actually written.
Initializing in your browser…
Turn audio into a waveform image in five styles, exported as PNG or real vector SVG. Reads every channel, shows true level in dBFS, and redraws correctly at any size.
Generate band-limited test tones, sweeps and noise from 20 Hz to 20 kHz. Up to eight voices, note-name entry, binaural beats, and WAV export rendered from the same oscillators you hear.
Detect tempo from onset autocorrelation, within 0.20 BPM across thirteen known-tempo fixtures. Draws the beats it found and plays them back as a click so you can check by ear.
A podcast host requires MP3 and your editor exported a WAV, and you want a specific bitrate rather than whatever the encoder feels like.
Input
episode.wav (44.1 kHz stereo) - MP3 - 320 kbps
Output
episode.mp3 measuring 322 kbps, estimate was within 0.6 percent
The bitrate is passed to the encoder now, which it was not: the conversion ran with no encoder arguments at all, so all four quality presets and the whole 64 to 320 kbps slider produced a byte-identical 157.0 KB file at libmp3lame’s 129 kbps default. Asking for 128, 192 and 320 now measures 129, 193 and 322 kbps with ffprobe on the download. Sample rate, channels and bit depth are controls too, and a WAV to FLAC round trip is bit exact.
Audio formats split into two families: lossy and lossless. Lossy codecs (MP3, AAC, OGG Vorbis, Opus) use psychoacoustic models to throw away sound data that the ear is unlikely to notice, masking effects from louder nearby frequencies, content above the upper limit of most adult hearing around 16-18 kHz, and subtle stereo details. A 3-minute song at 320 kbps MP3 is about 7 MB; the same song as uncompressed 44.1 kHz 16-bit stereo WAV is 32 MB. That roughly 4.5x ratio is the lossy compression at work, and for most content at most bitrates it is audibly transparent. Lossless codecs (FLAC, ALAC, WAV, AIFF) keep every sample bit-exact. FLAC typically compresses WAV by 40-50% through entropy coding without discarding any audio data, so a song that is 32 MB as WAV is 17-19 MB as FLAC. WAV is uncompressed PCM (the raw sample stream), with larger files but universally decodable at zero CPU cost. The practical matrix: use MP3 or AAC at 192-256 kbps for casual distribution, Opus for web streaming (better quality per bit than MP3), FLAC for archival of lossless masters, and WAV only when a downstream tool specifically requires uncompressed input.
Convert to a format your player, phone or car stereo actually supports, with M4A for Apple software and MP3 for everything else.
Turn large WAV recordings into MP3s small enough to email, at a bitrate you choose rather than one the encoder picks.
Take a lossless recording to FLAC for about 55 percent of the size, with the round trip bit exact.
Resample to 48 kHz so a video editor does not have to do it later.
Speech at 22.05 kHz mono is a quarter of the data of 44.1 kHz stereo and loses nothing that matters.
Bitrate is the main quality knob on lossy codecs. MP3 at 128 kbps is the floor where most listeners can hear compression artifacts (a slight "swirl" in cymbals, reduced high-frequency detail); 192 kbps is where most listeners stop hearing artifacts in casual listening; 256 kbps is transparent for nearly everyone on nearly all content; 320 kbps is the MP3 format's ceiling and the point of diminishing returns. AAC produces noticeably better quality than MP3 at equivalent bitrates: AAC at 128 kbps is roughly as good as MP3 at 192 kbps, which is why streaming services largely moved to AAC. Opus is the modern champion for new applications: at 96 kbps Opus matches MP3 at 192 kbps, and it handles both speech and music in one codec. For speech-only content (podcasts, voicemail, audiobooks) you can go much lower, with Opus at 24-32 kbps usable for speech.
Converting between formats is always a decode-re-encode operation except when both formats are lossless: FLAC to WAV is a decode-to-PCM operation with no information loss, and WAV to FLAC is a lossless compression pass. Everything else accumulates some degradation. Lossy-to-lossy conversion (MP3 to AAC, for example) decodes the MP3 to PCM, then encodes to AAC, so you lose whatever the AAC encoder would throw away on top of what the MP3 encoder already threw away. For this reason, keep lossless masters when possible and convert from the master for each distribution target, rather than chaining lossy conversions.
Sample rate and bit depth are separate parameters from bitrate. 44.1 kHz 16-bit is the CD standard and covers the full audible range (Nyquist gives 22.05 kHz bandwidth, comfortably exceeding the 20 kHz upper limit of human hearing). 48 kHz is the video and broadcast standard; convert audio for video work at 48 kHz to avoid resampling at the NLE stage. 24-bit depth matters for recording and mixing because it provides extra headroom and a lower noise floor, but for delivery 16-bit is indistinguishable from 24-bit on any consumer playback system. Higher rates (96 kHz, 192 kHz) are marketing rather than audibility: they make sense for pro audio archives but are wasted bits for casual listening.
About this tool specifically. Every setting on the page now reaches the encoder, which was not previously true: the conversion ran `ffmpeg -i input output.mp3` with nothing else, so the four quality presets and the 64 to 320 kbps slider changed nothing at all. Measured on a ten second fixture, every one of those settings produced a byte-identical 157.0 KB file at 129 kbps, which is simply libmp3lame's default. The same request now lands where it is asked: 128, 192 and 320 kbps produce 129, 193 and 322 kbps measured with ffprobe on the downloaded file, and the slider tracks the same way from 64 kbps up. The codec is named explicitly for each format rather than inferred from the file extension.
Sample rate, channel count and bit depth are controls now, where before there were none despite being the parameters this page spends most of its words on. Asking for 22.05 kHz mono returns a file that probes as 22050 Hz and one channel with the duration unchanged, and 24-bit WAV writes pcm_s24le rather than quietly staying at 16. A round trip from WAV to FLAC and back is bit exact, with a largest sample difference of zero.
The estimated size follows the settings that are actually sent, so it is now within one percent of the file that gets written, where the old estimate predicted 400 KB for a file that always came out at 157 KB. After a conversion the page decodes what it produced and reports the real size, effective bitrate, sample rate and channel count, so the outcome is measured rather than assumed. There are warnings for the two conversions that people most often regret: a lossy source into a lossless format, which makes a bigger file and not a better one, and a lossy source into another lossy format, which loses a little more each time.
It does now. It is passed to the encoder as -b:a, and the file that comes out measures within a percent or two of it: 128, 192 and 320 kbps produce 129, 193 and 322 kbps by ffprobe. In the previous build it did not: every preset and every slider position produced a byte-identical file at libmp3lame's 129 kbps default.
No, and the page warns you before it does it. What a lossy encoder discarded is gone; a lossless container just stores the decoded result exactly. It is worth doing when something downstream needs raw PCM, and worth nothing for quality.
For music, 192 to 256 kbps is transparent for most listening on most systems. For speech, 128 kbps is plenty, and dropping to mono at 22.05 kHz saves more than any bitrate change will.
Yes, and it was checked rather than assumed: a WAV converted to FLAC and decoded back matched the original with a largest sample difference of exactly zero.
Container overhead and, for MP3, the encoder rounding to the frame sizes it has available. The measured figure is typically about one percent over the target, and the panel shows both so you can see it.
Not yet. One file at a time; the previous copy on this page said otherwise and was wrong.
Audio is decoded and processed locally with the Web Audio API. Your files are never uploaded to a server.