Unless you’re living under a rock in 2023, you must have seen this keyword – somewhere working on any Restful API based web page or web app. This header I think would have been used in 99.8% of all the API calls that are done on internet or on the API’s that you might have tested- manually using Postman or using any DSL like Rest-Assured.

Modern api testing tools like Postman, Insomnia are intelligent enough to automatically add this header or provide this in the request/response of the API’s. But what is this header actually, what it does and why is it needed? Can we do without it.

Let’s see about that.

As per the Mozilla Developers Network (MDN), the Content-Type is defined as

The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending).
In responses, a Content-Type header provides the client with the actual content type of the returned content. This header’s value may be ignored, for example when browsers perform MIME sniffing; set the X-Content-Type-Options header value to nosniff to prevent this behavior.

Why is Content-Type Used

The Content-Type header in the request or response is added to tell the server or the browser or the medium which is serving the resource to the end user about the media type of the request or response.

The Content-Type header is a string that is sent along with the request or response and if it is a file that is associated with either the request or response, then the type is a string sent along with the file indicating the format of the file. For e.g. – when sending an image over an API, we can specify image/jpeg or image/png.

When Content-Type is sent in API response, it tells about the type of returned content, to the client -which in most cases is the browser. The browser gets to know about the type of content it has to load on the machine. Every time its byte stream of the file that browsers receive, by the Content-type header, the browser will do something known as MIME sniffing i.e. it will inspect the stream it is receiving and then loads the data accordingly.

When a resource are sent from the server to the client, the Content-Type header indicates what type of content it is receiving. This helps the browser prioritise resource rendering and know when to render them, potentially improving the page speed.

Directives

The Content-Type header consists of three different directives. These three directives have different purposes and need not necessarily be involved every type Content-Type header is specified.

  • MIME Type or the Media Type – For e.g – the most common that we all know is when we specify Content-Type as application/json when sending over a JSON data in a POST API call.

  • Charset – The encoding on the resource. Most often we will see charset=utf-8 , but this is not always and can change.

  • Boundary – This directive comes into picture when you’re dealing with entities with multi-part– may be a file that you are sending via an API over the network. Boundary is a string value that is used to encapsulate the parts of the message.  The boundary acts like a marker of each chunk of name/value pairs passed when a form gets submitted. The boundary is automatically added to a content-type of a request header. It should be less than 70 bytes long and should consist of 7-bit US-ASCII characters.

Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”file”; filename=”captcha”
    Content-Type:

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”action”

    submit
    -----WebKitFormBoundary7MA4YWxkTrZu0gW--

Do I Need to Specify It?

In most cases No. Most web browsers, API clients – e.g Postman, Insomnia etc are intelligent enough to add this content header to the requests/response that you make.

How can you test it?

Create a new request in postman with any given url. Select POST method and in the body, select form-data and then add a file and hit send. Let’s go step by step.

Select form-data from the body for a post request.

Use any name for the key and select any file – we just want to see what the output is

Once selected, hit send. Do not care about the response or any failure that comes.

Now go to the Headers section in the requests – you’ll see Postman has automatically added the Content-Type as multipart/form-data; boundary=<calculated when request is sent> in the request header.

It can be helpful in debugging where a page is not loading properly, for example with the Chrome Developer Tools,.The use of the content-type field in the server response is not mandatory, but it is desired.

Why should this be specified?

The Content-Type header, particularly in the server response makes it very easy for the client – in most cases, a browser to deal with the various resources sent out by the server.

The advantage of the specifying this header is also that the browser does not have to decide how to deal with the file. To give an example, this ensures that texts with a special character set, e.g. GB 18030, are recognised as such, since browsers that have not been given this information otherwise use the ISO-8859-1 character set for texts.

However, there are sometimes instances in which the browser tries to recognise the content type even when that content has been defined. This is called MIME sniffing, and it can be prevented with a special response header, the X-Content-Type-Options, through a nosniff directive.

What happens if I do not specify it?

If the client/browser doesn’t find this information in the response from server, then the browser must find this out itself. Most current browsers will read the first bytes of the file and try to compare them with the most common content types.

This can work well, but it does not always. Especially in the case of texts with unusual character encoding -for e.g. the above mentioned GB-18030, it can lead to a browser recognising text but incorrectly reproducing the special characters that it contains – that’s when many times you’ll see the characters from other languages like Hindi, Chinese etc coming incorrectly in the browsers – it may be due to this reason.

What are the different content types available

There are a lot of content types available. The full list is available here. Some of the most common Content-Type are

  • Application
 application/java-archive
 application/EDI-X12   
 application/EDIFACT   
 application/javascript   
 application/octet-stream   
 application/ogg   
 application/pdf  
 application/xhtml+xml   
 application/x-shockwave-flash    
 application/json  
 application/ld+json  
 application/xml   
 application/zip  
 application/x-www-form-urlencoded
  • Image
 image/gif   
 image/jpeg   
 image/png   
 image/tiff    
 image/vnd.microsoft.icon    
 image/x-icon   
 image/vnd.djvu   
 image/svg+xml
  • Multipart
 multipart/mixed    
 multipart/alternative   
 multipart/related (using by MHTML (HTML mail).)  
 multipart/form-data
  • Text
 text/css    
 text/csv    
 text/html    
 text/javascript (obsolete)    
 text/plain    
 text/xml

There are more than 100 different content types available. You can read from the link that I’ve provided.

I hope this blog was useful in making you understand what Content-Type header is and what is the importance of using that in our API calls.