MIME types and file extensions

What a MIME type is and where it comes from

A MIME type — formally a media type — is a two-part label, type/subtype, that tells a client what a stream of bytes is. On the web it arrives in the Content-Type response header, and it is the only authoritative signal. The file extension is a hint for the server, not for the browser; a file called photo.png served as text/plain displays as gibberish.

Types are registered with IANA. Anything beginning x- or vnd. is unregistered or vendor-specific — image/x-icon, application/vnd.rar — which is why those two prefixes appear so often in the list.

The five that break things most often

Wrong	Right	Symptom
image/jpg	image/jpeg	Some strict clients refuse the image; image/jpg has never existed
audio/mp3	audio/mpeg	Playback fails in Safari and some Android browsers
text/plain for JS	text/javascript	Script refused under X-Content-Type-Options: nosniff
application/octet-stream for wasm	application/wasm	instantiateStreaming throws
No charset on text/html	text/html; charset=utf-8	Accented characters render as mojibake

Content sniffing, and why nosniff exists

Historically browsers guessed the type when the header looked wrong, by examining the first bytes. That guess is a security hole: an uploaded file declared as text/plain but sniffed as text/html becomes stored cross-site scripting.

X-Content-Type-Options: nosniff turns the guessing off. It is the right header to send and it is also why a MIME type that used to “work” suddenly stops after a security review: the browser was covering for the misconfiguration, and now it will not. Serve the correct type and the problem disappears permanently.

The charset parameter

• text/* — always add it. The historical default is not UTF-8, and without the parameter older browsers and some tools fall back to Latin-1.
• application/json — never add it. The JSON specification fixes the encoding as UTF-8 and defines no charset parameter. Some strict parsers reject a request that includes one.
• Binary types — irrelevant. There is no text to decode.

Uploads: never trust the client’s type

The Content-Type on a multipart upload is set by the browser from the file extension, and an attacker can set it to anything. Validate server-side by reading the file’s magic bytes — %PDF, \x89PNG, PK\x03\x04 for anything zip-based including .docx and .xlsx — and re-derive the type yourself. Then serve user content from a separate origin with Content-Disposition: attachment where you can.

Forcing a download

Keep the correct type and add a disposition header:

Content-Type: text/csv; charset=utf-8
Content-Disposition: attachment; filename="report-2026-08.csv"

Deliberately mislabelling the file as application/octet-stream also triggers a download, but it breaks anything that inspects the type — previewers, virus scanners, and the operating system’s choice of application. Use the disposition header instead.

Multipart and the boundary

multipart/form-data is the only type where you must not set the header by hand. It carries a boundary parameter that has to match the delimiter used in the body, and the HTTP client generates both together. Setting Content-Type: multipart/form-data manually on a fetch with a FormData body strips the generated boundary and the server sees an empty form — one of the most common upload bugs there is.