MIME Types

Anatomy of a media type

A MIME type - properly called a media type - is the label a server attaches to a response so the client knows how to handle the bytes that follow. It has two parts separated by a slash: a top-level type such as text, image, audio, video, font, model or application, and a subtype that names the specific format. image/png and application/json are both complete media types; image alone is not.

Subtypes carry conventions of their own. A leading x- once marked an experimental type, as in application/x-tar, and although the practice is deprecated the surviving names are too widely deployed to change. A trailing +suffix says the format is built on a more general syntax: image/svg+xml is XML, application/ld+json is JSON, and a parser can fall back to the base syntax when it does not recognise the specific format.

Some types accept parameters after a semicolon. The most important is charset, as in text/html; charset=utf-8. Omitting it on a text response invites the browser to guess the encoding, which is a classic source of mojibake, so declaring UTF-8 explicitly is always worth the extra characters.

Why the header matters more than the extension

Browsers decide what to do with a response based on the Content-Type header, not the file name in the URL. Serving a PNG as text/plain shows a wall of binary garbage; serving JSON as text/html may cause a fetch client to reject it. Getting the header right is what makes a download open in the correct application and an inline asset render instead of downloading.

The mismatch has security consequences too. Older browsers practised MIME sniffing, inspecting the first bytes of a response and overriding a header they judged wrong. An attacker who could upload a file that looked like HTML could get it executed in the site's origin even when the server labelled it as an image. The X-Content-Type-Options: nosniff header disables that behaviour and is now standard practice on any endpoint that serves user-uploaded content.

For downloads, pair the media type with Content-Disposition: attachment; filename="report.pdf". The media type describes what the bytes are, the disposition describes what the browser should do with them, and the two answer different questions.

Where the mapping actually lives

There is no single authoritative extension-to-type table, which surprises people. IANA registers media types themselves, but the mapping from a file extension to a type is a local convention maintained by each server. Apache reads mime.types, nginx has its own mime.types file, and application frameworks ship their own lookup tables. That is why the same .wasm file can be served correctly by one server and as application/octet-stream by another that has not been updated.

application/octet-stream is the generic fallback meaning "arbitrary binary data". It is the honest answer when the format is genuinely unknown, but it defeats inline rendering, so it is worth adding an explicit mapping for any format your site serves regularly. Newer formats such as AVIF, JXL and WebAssembly are the ones most often missing from an older server configuration.