MIME types

What a media type actually is

A media type is two words with a slash between them. The part before the slash is the top-level type, a coarse bucket that tells software how to treat the data in general: can it be shown as text, does it need a player, is it a picture. The part after is the subtype, which names the specific format. In image/svg+xml, image says the data is a picture and svg+xml says exactly which kind, with the +xml suffix adding that it happens to be XML underneath, so a generic XML parser can also make sense of it.

The whole point is that the label travels with the data rather than with the filename. A web server sends it in the Content-Type response header, an email puts one on every part of a multipart message, and an HTTP client announces what it would like back in Accept. None of that involves the extension. That is also why renaming a file changes nothing about what it is, and why the identifier on this site reads the bytes instead.

Who decides which types exist

IANA maintains the media types registry, under rules set out in RFC 6838. Registering a subtype in the standards tree needs review; the vendor tree (vnd.) is open to whoever owns the format, which is why application/vnd.ms-excel exists without a standards process. The personal tree (prs.) is for individuals. A fourth convention, the x- prefix, marked something as unregistered and experimental until RFC 6648 deprecated it in 2012, for the good reason that temporary types never actually go away: application/x-7z-compressed is still what everything sends.

Top-level types are the closed part of the system. There are eleven registered: application, audio, example, font, haptics, image, message, model, multipart, text and video. New ones are rare and need a standards-track RFC. That is worth knowing, because plenty of real-world types are not registered at all. This database contains one: avro/binary, which the Apache Avro specification defines and which is genuinely used in Avro's own HTTP protocol, but which IANA has never registered. It is listed below under its own heading rather than beside the registered types, because presenting it as a peer of image would be wrong.

Parameters, and the ones that bite

A media type can carry parameters after a semicolon. The common one is charset, as in text/html; charset=utf-8, which says which encoding the bytes use. It applies only to text types, and getting it wrong is the classic cause of accented characters turning into pairs of symbols. Other parameters are format specific: boundary on a multipart type marks where each part begins, and codecs on a video type says which codec sits inside the container, which matters because video/mp4 on its own does not tell a browser whether it can actually play the file.

The fallback, and sniffing

application/octet-stream is the arbitrary-bytes type. A server sends it when it does not know what the data is, or when it wants the browser to download rather than display. Because misconfigured servers send it constantly, browsers do not simply trust the header: they also sniff, inspecting the first bytes and deciding for themselves. That behaviour is a security problem as much as a convenience, because a file sniffed as HTML can run script, which is why X-Content-Type-Options: nosniff exists to turn it off. The bytes browsers sniff are the same magic numbers catalogued on this site.

Frequently asked questions