In HTTP communications, data transmitted between clients and servers comes in many formats, from JSON documents and HTML web pages to images and plain text.

The Content-Type header acts as the representation metadata that tells the recipient how to interpret the bytes in the message body.

How Content-Type defines message representation

The Content-Type header specifies the media type (MIME type) of the payload body contained in an HTTP request or response:

  • In an HTTP request, it indicates the format of the data being sent to the server.
  • In an HTTP response, it indicates the format of the data returned to the client.

If a message does not contain a body (such as a standard GET request or a 204 No Content response), the Content-Type header is typically omitted.

Content-Type in requests

When a client sends data to an API endpoint using methods such as POST, PUT, or PATCH, an API may use Content-Type to determine how it should interpret a request body, depending on its contract and implementation.

For example, when sending a JSON payload to https://api.example.test/v1/users:

POST /v1/users HTTP/1.1
Host: api.example.test
Content-Type: application/json; charset=utf-8

{"username": "developer_example", "role": "engineer"}

Depending on the API contract, an incorrect or missing Content-Type can lead to a response such as 415 Unsupported Media Type or 400 Bad Request.

Content-Type in responses

When the server responds with content, Content-Type helps the receiving client decide how to handle the response representation:

HTTP/1.1 200 OK
Date: Thu, 10 Sep 2026 10:00:00 GMT
Content-Type: application/json; charset=utf-8

{"status": "success", "userId": "usr_example_123"}

If a server returns JSON data but labels it as text/plain, a client application or browser script expecting structured JSON might not parse the response automatically.

Common Content-Type values

Standard media types follow a type/subtype format with optional parameters:

  • application/json — Structured JSON data widely used in REST APIs.
  • text/html — HTML documents rendered by web browsers.
  • text/plain — Unformatted text data.
  • image/png — PNG image files.

Content-Type vs. Accept

Developers frequently confuse Content-Type and Accept. Although both deal with media types, they serve opposite directions:

  • Content-Type describes what is currently sent in the message body.
  • Accept is a request header that indicates media types the client can understand or prefers in a response.
Header Sent In Core Purpose Example Value
Content-Type Requests & responses with a body Informs recipient how to parse the enclosed payload application/json; charset=utf-8
Accept Client requests Indicates media types the client can understand or prefers in a response application/json, text/plain, */*

Content-Type and CORS preflight

When client-side JavaScript sends a cross-origin request from a browser, the value of the Content-Type header plays a significant role in browser security evaluations.

For a cross-origin browser request, a Content-Type value outside the CORS-safelisted media types can cause the browser to send a preflight request.

The CORS-safelisted Content-Type media types are:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

application/json is common and standard, but it is not one of those CORS-safelisted Content-Type values.

Content-Type is not the only factor: request method and other request headers can also affect whether a browser performs a CORS preflight.

Common debugging mistakes

When troubleshooting HTTP headers in APIs and web applications:

  1. Missing Content-Type on POST/PUT: Sending a JSON string without setting Content-Type: application/json causes backend body parsers to ignore or reject the request.
  2. Mismatched response types: Returning JSON with an unexpected Content-Type can require client-side code to handle the response differently or can lead to parsing failures, depending on the client.
  3. Expecting Content-Type to solve CORS: Modifying Content-Type on the frontend does not configure server CORS policies or replace server Access-Control-* response headers.

What to check before changing code

Before modifying frontend request builders or server deserialization middleware, check:

  1. What Content-Type header is the client actually transmitting in the network tab?
  2. Does the media type match the actual format of the serialized payload?
  3. Does the server require a specific charset parameter (e.g., application/json; charset=utf-8)?
  4. If a cross-origin preflight occurs, does the API server permit the Content-Type header in its Access-Control-Allow-Headers response?

Key takeaway

The Content-Type header describes the media type of the representation payload currently transmitted in an HTTP request or response. It is distinct from the Accept header, which negotiates desired response formats. On cross-origin browser requests, media types outside the CORS-safelisted set (such as application/json) can trigger an automatic OPTIONS preflight request.