Common MIME types every developer should know
A MIME type, also called a media type, is a short label that tells software what kind of data it is looking at. The name comes from email, where these labels were first defined, but they now appear everywhere on the web. When a server sends a file, it attaches the media type so the receiver knows whether it is reading HTML to render, JSON to parse, or an image to draw. Without it, the receiver has to guess, and guessing goes wrong often.
The structure: type and subtype
Every media type has the form type/subtype. The type is a broad category and the subtype names the specific format inside it.
text/html
application/json
image/png
The top level types you meet most are text for human readable formats, application for structured or binary data meant for a program, image for pictures, audio and video for media, and multipart for messages built from several parts, such as a form upload. Subtypes prefixed with x- were historically unregistered, and a + suffix marks a structured base, so application/ld+json is JSON shaped data following the JSON-LD convention.
The Content-Type header
On the web the media type travels in the Content-Type header. A server sets it on a response to say what it is sending, and a client sets it on a request body to say what it is uploading.
Content-Type: application/json
You can confirm exactly what a server returns by inspecting its response headers, which is useful when a file downloads instead of rendering or vice versa. The header may also carry parameters after a semicolon, the most common being the character set, and the client reads those together with the base type to decide how to handle the body.
The charset parameter
Text based types can carry a charset parameter that says how the bytes map to characters. For modern text you almost always want UTF-8.
Content-Type: text/html; charset=utf-8
If the charset is missing or wrong, accented characters, emoji, and non Latin scripts can appear as garbled symbols. Setting charset=utf-8 explicitly avoids the browser falling back to a legacy default.
Why the wrong type breaks things
The receiver acts on the declared type, not on the file extension or the actual contents. That has direct consequences.
- A JSON API that returns
text/htmlmay have its body parsed as markup or escaped by the client instead of decoded as data. - A PDF served as
application/octet-streamforces a download rather than opening in the browser viewer, because the generic binary type means "unknown bytes, save them." - A stylesheet served as
text/plainis ignored, because strict browsers refuse to apply CSS that is not labeledtext/css. - A correct image type such as
image/pnglets the browser render the image inline instead of offering to save an unknown file.
Browsers do try to recover through content sniffing, where they peek at the bytes to infer the real type, but you cannot rely on it. The X-Content-Type-Options: nosniff header exists precisely to turn sniffing off for security reasons, after which an incorrect Content-Type fails outright.
A short reference list
text/plain .txt
text/html .html
text/css .css
text/csv .csv
application/json .json
application/xml .xml
application/pdf .pdf
application/zip .zip
application/octet-stream arbitrary binary
image/png .png
image/jpeg .jpg .jpeg
image/svg+xml .svg
image/webp .webp
audio/mpeg .mp3
video/mp4 .mp4
font/woff2 .woff2
This covers the cases most web work runs into, but the registry is large and extensions map in both directions. When you need the right type for an unfamiliar extension, or want to see every extension a given type covers, the MIME Type Lookup resolves it instantly in your browser. To check what a live server is actually sending, view its HTTP Headers and read the Content-Type line directly.