Content negotiation is the part of HTTP that lets a client and server agree on how a resource should be represented. A single resource, say an article or a user record, can be rendered in many forms: as HTML or JSON or XML, in English or French, gzip-compressed or plain. Content negotiation is the process by which the two parties settle on a representation that suits the client without requiring a separate URL for every variant. The mechanism is defined in RFC 9110, “HTTP Semantics,” published in June 2022 as the consolidated, authoritative specification of HTTP’s semantics.
RFC 9110 distinguishes two strategies. In proactive negotiation, the client states its preferences up front using request headers and the server selects a representation on its behalf. In reactive negotiation, the server responds with a list of available representations and lets the client choose among them. Proactive negotiation is by far the more common in practice, because it requires only a single round trip and fits the way most clients and APIs are built.
Proactive negotiation is carried by a family of Accept headers. The client sends Accept to indicate which media types it can handle, Accept-Language for natural languages, Accept-Encoding for compression schemes, and Accept-Charset for character encodings. These headers support quality values, written as a “q” parameter, so a client can rank its preferences: it might say it prefers JSON but will accept XML, or prefers French but will take English. The server weighs these stated preferences against what it can actually produce and picks the best match.
The server then declares its choice with the Content-Type header. RFC 9110 describes Content-Type as representation metadata that “describes how content is intended to be interpreted by a recipient,” telling the client whether the bytes that follow are JSON, HTML, an image, or something else. Without it, the receiver would have to guess at the format, which is fragile and a source of security problems. Content-Type closes the loop that the Accept headers opened, turning a request for “something I can read” into a concrete, self-describing response.
Content negotiation is one of the features that lets the same Web infrastructure serve browsers, mobile apps, and machine-to-machine API clients from the same endpoints. A REST API can expose a resource at a stable URL and hand back HTML to a browser and JSON to a program, chosen by the Accept header rather than by a different address. This separation of the resource from its representation is a quietly powerful idea, and it is built directly into the semantics of HTTP itself.