Difference between the Accept and Content-Type HTTP headers

Question

So the Accept header tells the server the MIME-type of the resource the browser is looking for. For example, the server can send plain text, HTML, JSON, etc.

OK, that makes sense, but when I look at the Content-Type header and it seems to be doing the same thing. For example, it tells the server that it wants text or JSON.

So what is the difference between Accept and Content-Type HTTP headers?

Solution 1

As you correctly note, the Accept header is used by HTTP clients to tell the server what content types they'll accept. The server will then send back a response, which will include a Content-Type header telling the client what the content type of the returned content actually is.

However, as you may have noticed, HTTP requests can also contain Content-Type headers. Why? Well, think about POST or PUT requests. With those request types, the client is actually sending a bunch of data to the server as part of the request, and the Content-Type header tells the server what the data actually is (and thus determines how the server will parse it).

In particular, for a POST request resulting from an HTML form submission, the Content-Type of the request will (normally) be one of the standard form content types below, as specified by the enctype attribute on the <form> tag:

• application/x-www-form-urlencoded (default, older, simpler, slightly less overhead for small amounts of simple ASCII text, no file upload support)
• multipart/form-data (newer, adds support for file uploads, more efficient for large amounts of binary data or non-ASCII text)

Solution 2

• Accept: is what the browser is able to digest, for example, all the languages someone can understand.
• Content-Type: is what format the actual data is in, for example what language someone is speaking. Since computers can't (well, now they can) recognize other types like people can say "oh, he's German!" or "she's speaking Chinese!"

Solution 3

Accept is like

Here is my request and I would like (to Accept) this response format

Content-Type is like

Here is my request (or response) and this (Content-Type) is the format of the content I am sending in my request (or response)

Solution 4

It is a request-response conversation, so the client

• sends a request of "Content-Type" and
• expects to receive the response of "Accept" media type.

Solution 5

Accept

The Accept request HTTP header advertises which content types, expressed as MIME types, the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Type response header. Browsers set adequate values for this header depending on the context where the request is done: when fetching a CSS stylesheet a different value is set for the request than when fetching an image, video or a script.

(source: developer.mozilla.org)

Content-Type

The Content-Type entity header is used to indicate the media type of the resource.

In responses, a Content-Type header tells the client what the content type of the returned content actually is. Browsers will do MIME sniffing in some cases and will not necessarily follow the value of this header; to prevent this behavior, the header X-Content-Type-Options can be set to nosniff.

In requests, (such as POST or PUT), the client tells the server what type of data is actually sent.

(source: developer.mozilla.org)

View more solutions

Comments

[Todd Menier]

@darron No, this answer is correct. He's not saying it isn't a request header, he's saying its purpose is to tell the server what kind of response it expects to get back. Kind of redundant with the other answers, but I think it's the most concise. +1.

[shriek]

I know I'm late here but I'm curious, what would happen if the response format isn't sent in the "Accept"ed format by server?

[Jim Aho]

Not necessarily a browser, but any http client.

[Jim Aho]

That would be up to the client to decide @shriek. I guess most http clients (or browsers) will "intelligently" look at the real data and see what it truly is. Maybe one client could also disgard the response if it's supposed to be JSON, but parsing fails because it appears to be something else.