What a MIME type actually is
A MIME type, also called a media type, is a short label that tells software what kind of data a file or message body contains. It was born in email (the name stands for Multipurpose Internet Mail Extensions) but today it shows up everywhere on the web. The format is always type/subtype: a broad category, a slash, and a specific format. So text/html means "text, in HTML form", image/png means "an image, in PNG form", and application/json means "application data, encoded as JSON".
The top-level type comes from a fixed set maintained by IANA, the official registry: text, image, audio, video, application, font, model, multipart, and a few newer ones like haptics. The subtype is the specific format. Vendors can add their own with a vnd. prefix (for example application/vnd.ms-excel), and experimental types historically used an x- prefix, though that convention is now discouraged.
Where MIME types matter
The single most important place a MIME type appears is the HTTP Content-Type response header. When a server sends a page, an image, or an API payload, this header tells the browser how to interpret the bytes. If the header says text/html, the browser renders markup; if it says application/json, a fetch() call can parse it; if it says application/pdf, the built-in viewer opens. The same header travels on the request side too: when you POST a form or an API body, Content-Type tells the server how to read what you sent.
Beyond HTTP, MIME types drive several other systems. Email clients use them to decide whether an attachment is an image to preview or a binary to save. File-upload handlers inspect the declared type to accept or reject files. And the operating system or browser uses the type, not just the file extension, to pick a default application. The same idea underpins how servers report results and errors alongside HTTP status codes — a 200 response with the wrong type can be just as broken as a 404.
The ones you will use every day
A handful of types cover the vast majority of real traffic:
text/html— web pages (extension.html)text/css— stylesheets (.css)text/javascript— the recommended type for JavaScript (.js,.mjs)application/json— the one official JSON type, defined in RFC 8259 (.json)image/png,image/jpeg,image/webp,image/svg+xml— common image formatsapplication/pdf— PDF documents (.pdf)application/octet-stream— the catch-all for unknown or arbitrary binary datatext/plain— the default for plain text that has no richer type
JSON deserves a note because it trips people up. The only correct type is application/json. Older code sometimes used text/json, text/plain, or application/x-javascript, but those are obsolete and some clients will refuse to parse them. There is no charset parameter for JSON either — the spec mandates UTF-8, so writing application/json; charset=utf-8 is redundant though harmless. For a fuller table of formats and extensions, see our reference tables.
Why a wrong Content-Type breaks things
Browsers and clients trust the declared type, so getting it wrong has concrete consequences. Serve a JSON API response as text/html and the browser may try to render it, or a strict client may throw a parse error before your code ever runs. Serve a CSS or JavaScript file with the wrong type and a security feature called X-Content-Type-Options: nosniff will make the browser refuse to apply it, silently breaking your page styling or scripts.
Downloads are the other classic failure. If you want a file to download rather than display, the type matters alongside the Content-Disposition header. A PDF sent as application/octet-stream downloads as a generic file instead of opening in the viewer; an image sent as text/plain shows up as gibberish characters. On the upload side, a mislabelled file can sail past a naive extension check, which is why robust validators inspect the real bytes (the "magic number") rather than trusting the client-supplied type.
Historically, browsers tried to guess, or "sniff", the real type when the header looked wrong. That behaviour caused security holes, so modern best practice is to always send an accurate Content-Type and disable sniffing with nosniff. The short version: set the type deliberately on every response, and most rendering, download, and parsing bugs disappear.
Frequently asked questions
What is the difference between a MIME type and a media type?
They are the same thing. "MIME type" is the older name from email, while "media type" is the term IANA and modern HTTP specifications prefer. Both refer to the type/subtype label.
What is the correct MIME type for JSON?
It is application/json, defined in RFC 8259. Older alternatives like text/json or application/x-javascript are obsolete and some clients will reject them.
What does application/octet-stream mean?
It is the generic type for arbitrary binary data with no more specific label. Servers use it as a fallback for unknown file types, which usually triggers a download rather than in-browser display.
Why does my CSS or JavaScript file not load?
Often the server sends it with the wrong Content-Type. With X-Content-Type-Options set to nosniff, the browser refuses to apply CSS that is not text/css or scripts that are not a JavaScript type. Fix the server configuration so the right type is sent.
Can I add a charset to a MIME type?
Yes, for text formats, using a parameter like text/html; charset=utf-8. For JSON it is unnecessary because the format is always UTF-8 by specification, though adding it does no harm.
Does the file extension determine the MIME type?
Not over HTTP. The server decides which Content-Type to send, and the browser trusts that header. The extension only acts as a hint for tools and operating systems when no explicit type is provided.