MIME Types Reference

A MIME type — officially a media type — is a short label that tells a program what kind of data it is looking at. It always has the shape type/subtype: a top-level type such as text, image, audio, video, font, model, message, multipart or the catch-all application, followed by a specific subtype like png or pdf.

The name is a leftover from Multipurpose Internet Mail Extensions, the 1990s email standard where the concept was invented so that messages could carry images and attachments. The web borrowed it wholesale, and today the same registry of names is used by HTTP, email, and just about every file-handling API in between. IANA maintains the official list; anything starting with x- or vnd. is either unregistered or vendor-specific.

On the web the media type is delivered in the Content-Type response header, for example Content-Type: application/pdf. The same header appears on requests to describe the body you are sending — that is where application/json, application/x-www-form-urlencoded and multipart/form-data show up, none of which correspond to a file extension at all.

Browsers trust the Content-Type header over the file extension in the URL. A file named report.pdf served as application/octet-stream will not open in the built-in PDF viewer — it drops straight into the downloads folder, because octet-stream literally means "unknown bytes, hand them to the user". The same mistake turns an inline image into a download prompt and an HTML page into a wall of visible source code.

The failures that eat the most debugging time are the ones where the browser refuses the resource outright:

• ES modules. A <script type="module"> or a dynamic import() is rejected unless the response has a JavaScript MIME type. Serve a .mjs file as text/plain and the console says the module was blocked because of a disallowed MIME type — the file downloaded fine, it was just labelled wrong. This is the classic symptom of a static host that has no mapping for .mjs.
• Stylesheets. A <link rel="stylesheet"> whose response is not text/css is ignored in standards mode. The page loads unstyled and the network tab shows a perfectly successful 200.
• WebAssembly. WebAssembly.instantiateStreaming() requires application/wasm. Anything else falls over, which is why so many projects ship a manual ArrayBuffer fallback.
• Fonts and media. A font served as application/octet-stream usually still works, but <video> and <audio> use the type to decide whether they can play a source at all, and a WebVTT track that is not text/vtt is silently dropped.
• APIs. Send JSON without Content-Type: application/json and many frameworks will not parse the body, leaving you with an empty request object and a confusing 400.

The fix is almost always in the server, not the app: nginx reads mime.types, Apache reads mime.types plus AddType directives, and object stores such as S3 or R2 store the type as per-object metadata at upload time — which is why a file uploaded through the wrong tool keeps serving the wrong header until you re-upload or patch its metadata.

A media type can carry parameters after a semicolon, and for textual formats the important one is charset: Content-Type: text/html; charset=utf-8. The media type says what the bytes are; the charset says how those bytes map to characters. Without it the browser has to guess, and a guess of Windows-1252 or ISO-8859-1 is what produces the familiar mojibake where é renders as é.

Modern browsers default to UTF-8 in many cases and HTML has the <meta charset="utf-8"> fallback, but the HTTP header wins over the meta tag and is the only signal available for formats that have no place to declare their own encoding — CSV downloads, plain text, subtitle files, JavaScript modules. Declaring it explicitly costs nothing and removes a whole class of intermittent bug.

Two exceptions worth remembering. JSON has no charset parameter at all: the spec fixes the encoding to UTF-8, so application/json; charset=utf-8 is redundant and technically undefined — plain application/json is correct. And binary types ignore it: adding a charset to image/png is meaningless. The rule of thumb is that text/* and the XML-based +xml types want a charset; almost nothing else does.

Because so many servers were misconfigured, browsers historically second-guessed the header: if a response claimed text/plain but its first bytes looked like HTML, the browser would render it as HTML anyway. That behaviour is called MIME sniffing, and it is a security hole. If your site lets users upload a "text file" that actually contains <script> tags, a sniffing browser may execute it on your origin — a stored XSS delivered entirely through content sniffing.

Sending X-Content-Type-Options: nosniff switches that off. The browser takes the declared type at face value and, crucially, applies strict type checking to two categories: a script is blocked unless its type is a JavaScript MIME type, and a stylesheet is blocked unless it is text/css. Chrome extends this to Cross-Origin Read Blocking, refusing to hand cross-origin HTML, XML or JSON responses to an image or script tag.

The practical consequence: nosniff turns silent misconfiguration into a hard failure. Sites that "worked fine" before adding the header often break the moment it is enabled, which is a good thing — it surfaces the wrong Content-Type instead of papering over it. Send it on every response, and fix the types it exposes. Pair it with a correct Content-Disposition: attachment on user-uploaded files so they are downloaded rather than rendered on your origin at all.