MP3, WAV, FLAC: What Each Conversion Actually Destroys

Three formats, three different things being stored

A WAV file is a list of numbers with a short header in front of it. Each number is the position of a loudspeaker cone at one instant, measured a fixed number of times a second; the header says how many times a second, how many bits each number uses, and how many channels are interleaved. That is the entire format. The header this tool writes is the canonical 44 bytes and declares format tag 1, which is the registered identifier for plain PCM. Nothing is modelled, nothing is predicted, nothing is thrown away — which is why WAV is what every editor, every recorder and every signal-processing chain wants to be handed, and also why it is enormous.

FLAC stores the same numbers, but it looks for structure first: it fits a short polynomial to each block of samples, stores the coefficients, and then stores only the difference between the prediction and the truth, coded so that small differences are cheap. When even that would not help — on pure noise, say — it falls back to a verbatim block and simply writes the samples down unencoded, which is the mechanism that guarantees a FLAC is never meaningfully bigger than its input. How much smaller it gets is not a property of the format, and the project deliberately refuses to promise a figure: its own FAQ says the bitrate "is roughly proportional to the amount of information in the original signal", running from about 100 % of the input on noise down to almost nothing on silence. A sparse acoustic recording compresses well. A modern master squashed to the ceiling barely compresses at all. Both decode to exactly what went in.

MP3 and AAC store neither the samples nor a reversible transformation of them. They store a description of the sound as a hearing model perceives it, and everything that model rules inaudible — a quiet partial masked by a loud one nearby, detail above the frequency where the bit budget ran out — is not encoded at all. The decoder does not recover it; it synthesises something plausible in its place. For listening this is a triumph, and at 192 kbit/s most people cannot pick it out of the original in a fair test. For any further processing it is a trap, because the tools downstream will treat the synthesised part as if it were signal.

The only size formula you need to memorise

Bytes = sample rate × (bit depth ÷ 8) × channels × seconds, plus 44 for the header. Every term is something you can read off the file, and there is no compression to guess at. A three-and-a-half-minute song at CD settings is 44 100 × 2 × 2 × 210 = 37 044 000 bytes, or 37.04 MB. The same song as a 190 kbit/s MP3 is 4.99 MB, and the ratio between them — 1411.2 divided by 190, about 7.4 — is exactly the compression that lossy encoding buys and lossless encoding does not.

The two parameters in that formula are also the two the converter lets you change, and both have a physical meaning worth knowing before you touch them. The sample rate sets a hard ceiling on the frequencies the file can represent, at exactly half its value: 44.1 kHz can hold everything up to 22 050 Hz, comfortably beyond the top of human hearing, while 22.05 kHz cuts off at 11 025 Hz, which removes cymbals and sibilance but leaves speech entirely intelligible. The bit depth sets the distance between the loudest and quietest thing the file can hold, at roughly 6 dB per bit: sixteen bits gives about 98 dB of range, which is more than the difference between a whisper and a shout in any room you have ever been in.

Direction is everything

Between two lossless formats, conversion is free in both directions and only the size changes. FLAC to WAV gains you nothing you can hear and costs you roughly twice the disk space, so do it only when a program in front of you refuses FLAC — and plenty do, especially older editors and hardware samplers. WAV to FLAC is the same trade in reverse and is the correct way to archive anything, because the file that comes back out is bit-identical to the one that went in and you can verify that with a checksum.

Going from a lossy file into a lossless one is the conversion people expect the most from and get the least out of. Decoding a 190 kbit/s MP3 produces a full 1411.2 kbit/s PCM stream again — the samples come back at full rate, they are simply the wrong samples, the ones the decoder synthesised. Store that as FLAC and you get a file around four times the size of the MP3 that sounds exactly like the MP3. Nothing has been repaired; you have merely stopped the damage from getting worse, which is occasionally the right thing to do if the MP3 is the only copy that exists and you are about to edit it. Otherwise it is pure cost.

And lossy into lossy is the one to avoid entirely. Each pass encodes the previous encoder's artefacts as though they were music, spending bits to preserve noise while the real content loses another layer. That is why the professional habit is stated as a single rule: go lossy once, at the very end, on the finished thing. Every edit, every join, every level change, every normalisation happens on the lossless copy, and the MP3 or AAC is produced last, from the master, in one pass — never from another MP3.

What this converter is, and what it deliberately is not

It is a one-way door into WAV. It will read anything your browser can decode — MP3, M4A, AAC, OGG, FLAC and WAV are all on the accepted list — and it writes exactly one thing: 16-bit PCM in a WAV container, with an optional change of channel count and sample rate on the way through. It will not produce an MP3, and it will not produce a FLAC. That is a real limit and worth stating plainly rather than discovering: if what you need is an MP3 from an audio file, nothing on this site will make one for you. The extract-audio tool makes MP3, but only from a video.

Two consequences follow from the 16 bits. If your source is a 24-bit FLAC or a 24-bit recording from an interface, the WAV that comes out has eight fewer bits of dynamic range — 98 dB instead of about 146 — and the conversion is undithered, so the truncation error appears as a very quiet noise floor rather than being spread out. On a mixed and mastered piece of music nobody will hear it. On a quiet field recording you intend to normalise upward by 30 dB, you will. And if your source is a 32-bit float file from a modern recorder, the clamp to plus or minus one is not a formality: anything that went above full scale in the float domain, which is exactly what 32-bit float recording exists to allow, is flattened at the ceiling here rather than being brought down first.

The sample rate it shows you is your speakers', not your file's

Load a file and the tool prints a line like "Source: 48000 Hz · Stereo". It is easy to read that as a fact about the file. It is not, or at least not reliably, and the reason is written into the Web Audio specification: decoding takes the result and resamples it "to the sample-rate of the BaseAudioContext if it is different from the sample-rate of audioData". The context here is created with no options, and a context created that way uses the sample rate of the default output device. So the number you see is the rate your machine's audio output happens to be running at — commonly 48 000 Hz on a laptop, sometimes 44 100, occasionally 96 000 if you have a professional interface configured that way.

The practical consequences are small but specific. "Keep" keeps the decoded rate, not the file's original rate, so a 44.1 kHz album track opened on a machine running at 48 kHz comes out as a 48 kHz WAV that is about 8.8 % larger and has been resampled once. Asking explicitly for 44 100 does not undo that — it resamples a second time, back down. Neither pass is audible in any ordinary sense; both are interpolation, done by the browser's own resampler, and the result is a good approximation rather than the original numbers. So: if you need bit-exact PCM out of a lossless source — for a checksum, for a forensic comparison, for a mastering chain — this is not the tool, and no browser tool built on this API can be. If you need a WAV that plays correctly and sounds right, which is what almost everybody needs, it is exactly the tool, and the rate on the readout is a fine thing to ignore.

Choosing mono, and choosing a rate, without kidding yourself

Mono halves the file and is the right answer more often than people expect, because a great deal of recorded material has no stereo information in it at all: a single voice into a single microphone, a phone memo, a lecture, an interview. Folding those to mono removes a duplicate, not a dimension. It is the wrong answer for anything with a stereo image you care about — music, ambience, anything recorded with two microphones and a distance between them — and it is not reversible: once the two channels are summed, no later step can pull them apart. The safe habit is to keep a stereo copy of the original and let mono be an export.

On the rate, the honest position is that 44.1 kHz and 48 kHz are interchangeable for listening and that the choice is entirely about what is downstream: video work is conventionally 48 kHz because that is what the containers and the broadcast chain use, music distribution is conventionally 44.1 kHz because that is what the compact disc used, and converting between them is a resampling operation rather than a relabelling. Do it when a destination demands it, not for tidiness. The 22.05 kHz option is a different kind of decision: it is a deliberate bandwidth cut to 11 025 Hz, it makes a speech file 4.35 times smaller than a 48 kHz stereo one when combined with mono, and it is exactly right for a transcription upload and exactly wrong for anything anybody will listen to for pleasure.

Frequently asked questions

Does converting my MP3 collection to FLAC improve the sound?

No, and the arithmetic shows why. Decoding a 190 kbit/s MP3 gives you back a full-rate PCM stream at 1411.2 kbit/s, but those samples are the decoder's reconstruction, not the original recording. FLAC then compresses that reconstruction perfectly — which is the problem: it preserves, with total fidelity, exactly the damaged signal you gave it. You end up with a file roughly four times the size of the MP3 that is indistinguishable from the MP3 in a blind test, because it is the MP3, just written down differently. The only thing you gain is that no further generation will be added by whatever you do next, which is worth having if you are about to edit and worth nothing if you are about to listen.

Is 48 kHz better than 44.1 kHz?

Not in any way you can hear. A sample rate sets the highest frequency a file can carry, at exactly half its value, so 44.1 kHz reaches 22 050 Hz and 48 kHz reaches 24 000 Hz — both comfortably above the top of human hearing, which in practice stops well short of 20 000 Hz and falls with age. The two numbers exist for historical and industrial reasons rather than acoustic ones: 44.1 came from the compact disc, 48 from professional video and broadcast. Choose whichever your destination expects, and convert only when something in the chain demands it, because converting is a resampling operation with its own small imperfections rather than a free relabelling.

The tool says my file is 48 000 Hz but I know it is a 44.1 kHz rip. Which is right?

You are, about the file; the tool is, about what it has in memory. The Web Audio decoding step resamples the decoded audio to the sample rate of the audio context, and the context is created with no rate specified, which means it takes the rate of your default output device. So the reading tells you what your speakers are running at, and the decoded audio really has been converted to that rate before the tool ever sees it. If you need the file's declared rate, read it in a media player or a file-inspection tool instead. If you just need a usable WAV, this changes nothing you will notice — but it is the reason a file can come out slightly larger than the arithmetic on its original rate predicted.

Can I get an MP3 out of this tool?

No. It writes WAV and only WAV, because it is built on the browser's own audio decoding rather than on a bundled encoder: the browser will decode an MP3 for it, but it will not encode one. That asymmetry is not an oversight, it is how the platform works. If your source is a video rather than an audio file, the extract-audio tool does have an MP3 encoder — a WebAssembly build of LAME — and will give you one directly. If your source is already audio and you need an MP3 out of it, you will need something outside this site for that final step. Which, given the rule about going lossy once at the end, is usually the step you should be doing last anyway.

My FLAC will not open in the converter at all. Why?

Because the decoding is the browser's, not the tool's, so what opens depends on which codecs your browser ships. FLAC has been decodable in the major desktop browsers for years, but a high-resolution file can still fail for a different reason: the format allows sample rates up to just over a megahertz and bit depths from 4 to 32, and a browser's decoder is not obliged to accept the whole range. If a 192 kHz or 24-bit file refuses, try it in another browser before concluding the file is broken, and check that the file plays elsewhere at all. The same applies in reverse to formats like Opus or old Windows Media files: what the accept list offers is a superset of what any single browser can actually read.