MP3 MIME Type – Free, Online, Private

What .mp3 is

MP3 is MPEG-1 or MPEG-2 Layer III audio. A file may start with an ID3v2 tag, which is the ASCII bytes ID3, or it may start directly with a frame sync of 11 set bits, visible as FF Ex or FF Fx. There is no single container box. Duration is not stored in a header you can trust unless a Xing or Info frame is present, so players estimate it from the bitrate and the length. The registered media type is audio/mpeg. RFC 3003 covers MPEG audio, and .mp3 is the extension everyone means.

IANA registers audio/mpeg in RFC 3003. audio/mp3 is not the registered type. The media type is audio/mpeg. Extensions that use it on this page: .mp3. 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/mpeg

What sends audio/mpeg: Send audio/mpeg for a .mp3 response that an audio element, a podcast client, or a download should accept. Include Accept-Ranges: bytes if you want seeking. Players issue Range requests to jump, and a server that ignores Range and returns 200 with the whole file still works, slowly. Do not send audio/mp3 if you are writing a new configuration. Browsers tolerate it. Strict podcast feeds and some CDNs' allow lists do not. ID3 is metadata inside the file. It is not a MIME parameter. The file on disk is still .mp3. Once the response exists, a client trusts audio/mpeg, not the filename. If you negotiate an Opus or AAC variant on the same URL, change the Content-Type with the bytes and send Vary: Accept. A cache that stores audio/mpeg against an Opus body will ship silence to the next client. Keep one canonical encoding per URL when you can.

Content-Type for .mp3

Send audio/mpeg 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/mpeg

nginx, Apache, and Express

These snippets map .mp3 to audio/mpeg. 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 .mp3 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/mpeg                  mp3;

ApacheAddType audio/mpeg .mp3

Expressimport express from "express";

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

Pitfalls for audio/mpeg

Pitfalls that show up for audio/mpeg, and not for a neighboring type with a similar extension: A file that is actually AAC in an ADTS stream, or a renamed M4A, will not start with a frame sync or ID3. Labeling it audio/mpeg makes the audio element fail after a long timeout. Check the sync. Another trap is a mislabeled MIME on a podcast RSS enclosure. Clients download the enclosure based on the type attribute and then refuse to play it. A third is omitting the length, so a player cannot show a progress bar. Content-Length, or a correct Content-Range on a 206, fixes that. A fourth is treating MPEG audio as safe to gzip. It is already compressed. Gzip wastes CPU.

• audio/mpeg is also a plausible type for MPEG-1 Layer I and II. If you only accept MP3, check the layer bits in the frame header.
• ID3v1 is 128 bytes at the end of the file, not the start. A signature check that only looks at byte zero still has to allow FF.
• VBR files without a Xing header seek poorly. That is a file problem, not a reason to change the type.
• Do not send a charset. The stream is binary.