Content-Type
The HTTP Content-Type header indicates the media type of the resource in the message body.
Usage
The Content-Type header tells the client (or server, for request bodies) the media type of the enclosed content. The media type determines how the recipient parses and renders the body. Without this header, clients resort to MIME sniffing, which introduces security risks and inconsistent behavior.
A media type consists of a top-level type and a subtype separated by a slash, optionally followed by parameters. The Accept request header works alongside Content-Type during content negotiation, letting the client express preferred media types before the server selects one.
Servers and intermediaries sometimes apply Content-Encoding (such as gzip or br) before transmission. The Content-Type header always describes the original media type before encoding, not the encoded format.
The MIME-Version header traces back to the email origins of MIME types and appears in some HTTP messages, though HTTP does not require the header for media type processing.
Parameters
media-type
The media type value follows the type/subtype format
registered with IANA. Common types include text/html,
application/json, image/png, and
application/octet-stream. A
complete registry
is maintained by IANA.
charset
The charset parameter specifies the character encoding of
text-based media types. UTF-8 is the dominant encoding on
the web.
Content-Type: text/html; charset=UTF-8
boundary
The boundary parameter is required for multipart/* media
types. The boundary string separates each part of the
multipart body. The boundary value must not appear within any
of the body parts.
Content-Type: multipart/form-data; boundary=----FormBoundary
Example
A server returns an HTML page with UTF-8 encoding. The browser uses the media type to render the content as a web page and the charset to decode the text correctly.
Content-Type: text/html; charset=UTF-8
An API returns a JSON response. The application/json media
type instructs the client to parse the body as JSON.
Content-Type: application/json
An API error response uses the
application/problem+json media type to signal a
structured problem details payload.
Content-Type: application/problem+json
A CDN converts an HTML page to Markdown on the fly
when the client sends Accept: text/markdown. The
response carries text/markdown as the content type,
signaling the body is Markdown rather than HTML.
Content-Type: text/markdown; charset=utf-8
AI agents and Content-Type
CDN providers like Cloudflare return
Content-Type: text/markdown alongside an
x-markdown-tokens header estimating the
token count of the converted document.
Agents use the content type to select the
correct parser and the token estimate to
manage context window budgets.
A file upload uses multipart/form-data with a boundary
string separating the form fields and file data within the
request body.
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
A server delivers a binary file download. The
application/octet-stream type signals raw binary data,
often paired with a
Content-Disposition header set to
attachment.
Content-Type: application/octet-stream
A multipart/byteranges response delivers multiple byte
ranges from a single resource. Each part has its own
Content-Type and Content-Range header.
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Takeaway
The Content-Type header declares the media type and optional parameters (charset, boundary) for the message body, enabling correct parsing, rendering, and content negotiation between clients and servers.
See also
- RFC 9110: HTTP Semantics - Content-Type
- Accept
- Content-Encoding
- Content-Disposition
- MIME-Version
- Problem details
- HTTP headers