AAC MIME Type – Free, Online, Private

What .aac is

A raw AAC file on the web is usually ADTS: a series of frames, each starting with a sync word of 12 bits set to one, so the first byte is FF. The header carries the profile and the sample rate. There is no movie box and no index. Duration is estimated unless something else records it. That is different from .m4a, which is AAC inside an MP4 container and uses audio/mp4. Sending audio/aac for an M4A file, or audio/mp4 for a naked ADTS file, is the mix-up this page is here to prevent.

IANA registers audio/aac. The media type is audio/aac. Extensions that use it on this page: .aac. 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/aac

What sends audio/aac: Send audio/aac for a .aac ADTS response. An audio element can play it in browsers that include an AAC decoder, which is most of them, but the lack of a container means seeking depends on the player rereading frame headers. Prefer audio/mp4 with an .m4a file when you want reliable duration and seeking. Do not add a charset. If a live stream uses ADTS over HTTP chunked transfer, the type is still audio/aac and Content-Length may be absent. Say so. Players treat a missing length as a live or unknown duration. The file on disk is still .aac. Once the response exists, a client trusts audio/aac, not the filename. For a file you control end to end, put AAC in an MP4 and serve audio/mp4. Keep audio/aac for the case where the producer handed you ADTS and you are not remuxing. Remuxing to MP4 does not re-encode. It is cheap compared with a second lossy pass, and it gives you a duration.

Content-Type for .aac

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

nginx, Apache, and Express

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

ApacheAddType audio/aac .aac

Expressimport express from "express";

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

Pitfalls for audio/aac

Pitfalls that show up for audio/aac, and not for a neighboring type with a similar extension: The bug is a converter that writes ADTS and a config that copies the MIME type from a sibling .m4a route. The element fires an error and the file is not 'corrupt' in the sense of bad AAC. It is the wrong envelope. Another trap is HE-AAC with SBR, which a decoder without SBR plays at half speed or not at all. The type does not express the profile. If the client needs to know, document the profile next to the URL. A third is assuming AAC is free of patent questions in every distribution channel. The header cannot answer that.

• ADTS sync is FF F0 or similar, which also looks a bit like MP3 sync. Check the layer bits before you call it MPEG audio.
• audio/aacp is an old unofficial value for HE-AAC. Prefer audio/aac unless a specific client demands the alias.
• A .aac file with an ID3 tag in front exists. Players differ. Stripping the tag is safer than inventing a type.
• Do not gzip ADTS and forget Content-Encoding. The sync words will not be where the decoder looks.