HTTP headers · Request and response
Content-Type
Content-Type states the media type and optional parameters of the request or response body.
Key facts
| Type | Request and response |
|---|---|
| Syntax | <code>text/html; charset=utf-8</code> |
| Media type | <code>type/subtype</code> |
| Parameters | <code>charset</code>, <code>boundary</code> |
| Default | None; recipients may sniff |
| Scope | Describes the body, not the URL |
| Standard | RFC 9110 §8.3 |
A media type, not a filename
The value is a media type from the IANA registry, optionally followed by parameters. text/html; charset=utf-8 tells the receiver both the format and the character encoding. The file extension in a URL is irrelevant; only this header and the bytes decide how a body is interpreted.
For multipart bodies, boundary is mandatory and must match the separators inside the body. For JSON, the registered type is application/json; the older text/json is not standard and some clients refuse it.
Sniffing and security
When the header is missing or wrong, browsers may sniff the body and treat it as HTML. That turns an uploaded text file into executable markup. X-Content-Type-Options: nosniff disables this behaviour and makes the declared type authoritative.
Set the header explicitly on every response, including errors. A 404 page rendered as text/plain looks broken, while a JSON error labelled text/html can be rendered as a page.
Frequently asked questions
Does charset apply to JSON?
JSON is defined as UTF-8, so a charset parameter is unnecessary; some parsers accept it, but the encoding is not negotiable.
Should I use application/json or text/plain?
Use application/json for JSON. text/plain tells clients the body is uninterpreted text and loses structured handling.