Glossary

MIME type

A MIME type identifies the kind of content represented by a message or file. It helps select the correct parser, rendering or download behaviour, but does not prove that the content is safe or that someone is authorized to open it.

Short definition

An agreement about the content format, not merely a file extension.

The name MIME comes from Multipurpose Internet Mail Extensions, though the broader term media type is now more common. Its notation has the form type/subtype, such as text/html, application/json or image/png. It can also include a parameter, typically charset=utf-8, which specifies the character encoding for text content.

In web communication, the server usually sends Content-Type in an HTTP response, while the client specifies Content-Type for the request body. The Accept header instead indicates which response representations the client can process. These details provide a common language for communication, but the application still validates data, size and permissions separately.

The problem it solves

It tells both sides how to interpret a message body or file.

Without type information, browsers, API clients and servers would have to guess the content format from a filename or their own rules.

a browser distinguishes an HTML document, CSS, JavaScript, an image, a font and a downloadable file
an API selects a JSON or XML parser and can reject a body in an unsupported format
an upload service applies the appropriate rules for a document, image or another permitted file type
an order export indicates whether the response is a CSV, PDF or JSON error
HTTP caches and security rules work with the actual type of the returned content

Practical example

A JSON API and an order export use different response types.

An administration interface asks the API for order details and expects JSON. Another endpoint offers an export for accounting; it is appropriate to identify that file as text/csv with UTF-8 encoding, for example. The client should not guess the content from only the filename or URL path.

If an uploaded file declares image/png, the server still performs its own checks under the service rules. A missing or forged header therefore does not turn a prohibited file into a safe image.

HTTP

GET /api/orders/ord_8f2c HTTP/1.1
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

How it works

The content type connects an HTTP message to the appropriate processing.

The type identifier is metadata. Depending on the risk of the operation, a correct implementation verifies both the header and the actual data.

The client states its expectations For example, Accept: application/json tells an API that the client expects JSON. The server need not satisfy every preference, but should respond predictably.
The sender describes the body A request containing JSON carries Content-Type: application/json. A form upload commonly uses multipart/form-data with separate parts.
The server selects a parser An endpoint accepts only the formats supported by its contract. It then handles syntax, size limits, data types and authorization.
The response has its own type An API can return application/json, an export can use text/csv, and a product image can use image/jpeg. The browser chooses appropriate handling based on the type.
The client processes the content safely The type helps choose a procedure, but must not lead to unrestricted execution or rendering of untrusted content.

Important concepts

Type, subtype, parameter and response negotiation.

Common examples are registered with IANA, but their use is also governed by the contract of the specific endpoint.

Content-Type

This header describes the format of the body of the message currently being transferred. Examples include text/html; charset=utf-8 in a response and application/json in an API.

Accept

This request header specifies acceptable response types. It is not the same as Content-Type: it describes the client's preferences, not the body being sent.

Text and character encoding

text/html, text/css and other text types may need a charset. UTF-8 is the usual choice for the modern web, but the type and encoding are two separate pieces of information.

Media type and extension

A .png or .json extension is a useful hint for people and the file system. A server must not treat it as proof of the content, because it can easily be changed.

Generic binary data

application/octet-stream identifies unspecified binary data. It says neither that the file is safe nor how to open it safely or who should be allowed to access it.

Benefits and limitations

Clearer communication without a false sense of security.

Benefits

the client can select the correct parser or rendering method
the server can reject an unsupported format before unnecessary processing
API documentation becomes more specific and exports more predictable for users
standardised values improve interoperability between applications

Limitations and mistakes

neither a file extension nor a client-supplied Content-Type reliably proves the actual format
an incorrect header can make a browser display or download content differently from what the application expects
the content type does not validate a JSON or XML schema or any business rules
an upload remains dangerous without size limits, risk-appropriate malware checks and server-side format validation
Content-Type does not replace authentication and authorization for a file or endpoint

Practical use

Use precise values and predictable errors for both APIs and files.

An endpoint that creates an order may accept only application/json and return a clear error for any other type. An export endpoint can instead return text/csv or application/pdf in response to an explicitly supported Accept value. In both cases, documenting the type, encoding, size limits and behaviour for an invalid body is useful.

For uploads, trusting a browser header is not enough. The application limits size, checks actual signatures or content with a suitable server-side tool, stores files outside the public document root, and decides whether they may be downloaded based on permissions. When displaying user-uploaded content, a separate domain, secure headers, or forced download may be safer depending on the specific risk.

What to consider

Validate the format at the system boundary and send it consistently.

Most problems arise when the filename, HTTP header, actual data and documentation all say something different.

specify the supported Content-Type and Accept values in the API contract and test unsupported formats
send JSON as application/json and XML as application/xml rather than relying on a URL extension
use and document UTF-8 consistently for text content
validate several properties of an uploaded file and do not automatically render it as active content
do not store sensitive exports in a publicly accessible path merely because they have the correct MIME type
log metadata with privacy in mind and do not record the entire request body without a reason

Common questions

MIME types in practice

Is a MIME type the same as a file extension?

No. An extension is part of a filename, while a MIME type describes the content format. Both an extension and a client-supplied header can be changed, so a server must not use either as its only check.

What is the difference between Content-Type and Accept?

Content-Type describes the body of the message currently being sent. Accept states which response types the client can or wants to receive.

Is application/octet-stream a safe type?

No. It identifies unspecified binary data. It says nothing about the safety, permissions or specific format of the file.

Is checking the upload MIME type in the browser enough?

No. Browser checks are a user convenience; depending on the risk, the server must validate the size, actual content, storage and access rules.

How I work with APIs and data exchange

I connect the transport format with the contract, validation and secure processing.

For APIs and integration scenarios, I address compatibility, authentication and clear error states in addition to the content type.

How I work with APIs and integrations Discuss your project without obligation