WAV MIME Type – Free, Online, Private

What .wav is

A WAVE file is RIFF. Bytes 0-3 are RIFF, bytes 8-11 are WAVE, and a fmt chunk describes the codec, the sample rate, and the channel count. PCM is codec 1. IEEE float is codec 3. A data chunk holds the samples. The file can be large because PCM is uncompressed. Browsers recognize audio/wav and audio/wave and audio/x-wav to varying degrees. The value to send is audio/wav, which is what the audio element and the major static servers agree on. RFC 2361's audio/vnd.wave; codec=1 form is the historic registry entry and is not what a browser audio element is looking for.

Servers and browsers use audio/wav. RFC 2361 describes audio/vnd.wave with a codec parameter for the historic WAVE registry. IANA's current media-type list does not register audio/wav. The media type is audio/wav. Extensions that use it on this page: .wav. A client compares the type, not the filename, once the response has arrived. The filename still matters on disk and in Content-Disposition, which is why a wrong extension and a wrong header are two different bugs.

What sends audio/wav

What sends audio/wav: Send audio/wav for a download or for short UI sounds where you want to avoid a lossy encode. For music and podcasts, transcode to audio/mpeg, audio/mp4, or audio/ogg and send that type instead. Seeking still wants Accept-Ranges: bytes. A WAVE file's data chunk can be huge, so a server that buffers the whole body before sending will spike memory. Stream it. Do not add a charset. The fmt chunk is binary. The file on disk is still .wav. Once the response exists, a client trusts audio/wav, not the filename. Say in the API whether you accept float and extensible format chunks. Lots of DAW exports are WAVE_FORMAT_EXTENSIBLE, codec 65534, with a subtype GUID in the fmt extension. Calling that audio/wav is correct and still not enough for a decoder that only implements PCM 16-bit.

Content-Type for .wav

Send audio/wav and do not add a charset parameter. The body is binary. A charset tells a text decoder to reinterpret bytes that are not text, which corrupts a download and does not help a browser sniff the format.

Content-TypeContent-Type: audio/wav

nginx, Apache, and Express

These snippets map .wav to audio/wav. nginx reads the types block when it picks a type from the URL's extension. A location that sets default_type, or an application that sets the header itself, overrides that map. Apache AddType applies in the directory context where you put it. The Express static example writes the header for files ending in .wav so a stale mime database in the framework cannot disagree with the type on this page.

nginx# /etc/nginx/mime.types, inside the types { } block
audio/wav                   wav;

ApacheAddType audio/wav .wav

Expressimport express from "express";

const app = express();
app.use(express.static("public", {
  setHeaders(res, filePath) {
    if (filePath.endsWith(".wav")) {
      res.setHeader("Content-Type", "audio/wav");
    }
  },
}));

Pitfalls for audio/wav

Pitfalls that show up for audio/wav, and not for a neighboring type with a similar extension: The practical bug is a mime.types line that says audio/x-wav and a client that only allows audio/wav. Pick audio/wav. Another bug is a 24-bit or float WAV that a browser cannot decode even though the type is right. Offer a 16-bit PCM export if the page has to play the file. A third is treating the RIFF size field as authoritative when the file was appended to. Trust the socket's content length, and reject a size that claims to run past the body.

• RF64 and BW64 are large-file variants. A decoder that only understands classic RIFF will stop. The type is still audio/wav in common practice, and you should test the player.
• audio/wave and audio/x-wav are aliases. New configuration should send audio/wav.
• A LIST or INFO chunk can hold a title. It is not a substitute for a filename in Content-Disposition.
• Gzip on PCM audio does help, unlike MP3. If you gzip, keep Content-Type: audio/wav and set Content-Encoding.