When developing web applications and REST APIs, it’s essential to understand how data is sent in HTTP requests. One of the key components for this is the Content-Type header, which tells the server (or client) the format of the data in the request body.
In this article, we’ll explore the main Content-Type values, explaining when to use each, their structure, practical examples, advantages, disadvantages, and useful tips to help you choose the right one for your project.
What is Content-Type?
The Content-Type header is part of the HTTP specification and indicates the media type (MIME type) of the request or response body. It is essential so the server knows how to interpret the data received and respond appropriately.
Example:
POST /api/user HTTP/1.1
Content-Type: application/json
{
"name": "John",
"email": "john@example.com"
}
By setting Content-Type: application/json, we explicitly inform that the request body contains a JSON object. This is crucial so the server can properly parse and convert the data into an appropriate internal structure.
Without this header, the server might misinterpret the content, causing read errors, conversion failures, or unexpected responses.
application/json
This is the most widely used Content-Type in modern REST APIs. It indicates that the request body is in JSON format (JavaScript Object Notation), a lightweight and human-readable format used to represent objects, arrays, strings, numbers, and booleans.
Use case: Ideal for modern web services, as most programming languages offer native support for JSON parsing and serialization.
Example:
var httpClient = new HttpClient();
var url = "https://jsonplaceholder.typicode.com/posts";
var newPost = new
{
title = "HTTP Request Body Types (Content-Type)",
body = "Learning about HTTP request types at NWE",
userId = 1
};
var json = JsonSerializer.Serialize(newPost);
var content = new StringContent(json, Encoding.UTF8, "application/json");
var response = await httpClient.PostAsync(url, content);
Advantages:
Lightweight and easy to read by both humans and machines.
Natively supported in most languages.
Ideal for RESTful APIs.
Works well with front-end frameworks (Angular, React, Vue).
Supports nested structures (objects and arrays).
Disadvantages:
Not suitable for binary file uploads (images, etc.).
May require manual validation and serialization in some environments.
multipart/form-data
Used primarily when sending files or mixed data (text + files) in a single HTTP request—especially in HTML forms with input type="file".
This type splits the request body into multiple parts, each separated by a boundary string. Each part represents a form field or a file.
Example:
var httpClient = new HttpClient();
var url = "https://httpbin.org/post";
var filePath = @"C:\Users\Pictures\photo.png";
using var fileStream = File.OpenRead(filePath);
using var form = new MultipartFormDataContent();
form.Add(new StringContent("John Doe"), "name");
form.Add(new StreamContent(fileStream), "file", "photo.png");
var response = await httpClient.PostAsync(url, form);
var result = await response.Content.ReadAsStringAsync();
Advantages:
Allows sending binary files (images, PDFs, etc.) and text fields together.
Widely used in file upload forms.
Well supported in browsers and frameworks.
Disadvantages:
More complex to serialize/deserialize compared to JSON or URL-encoded formats.
Larger and less efficient payloads.
application/x-www-form-urlencoded
One of the oldest and most widely used formats for sending data in HTTP requests—especially for simple HTML forms.
Data is encoded as key=value pairs, separated by &. Special characters are URL-encoded (e.g., space becomes %20 or +). This data is usually sent in the body of a POST request.
Example:
var httpClient = new HttpClient();
var url = "https://httpbin.org/post";
var formData = new Dictionary<string, string>
{
{ "username", "john" },
{ "age", "19" }
};
var content = new FormUrlEncodedContent(formData);
var response = await httpClient.PostAsync(url, content);
var result = await response.Content.ReadAsStringAsync();
Advantages:
Lightweight and easy to generate (great for simple forms).
Supported by all browsers.
Easy to work with using
HttpClientor jQuery.
Disadvantages:
Doesn’t support file uploads.
Data must be URL-encoded manually.
Flat structure—no support for nested objects or arrays.
application/xml
Used when sending structured data in XML format. Common in integrations with legacy systems, SOAP services, or APIs that adopt XML as the communication standard.
XML organizes data in hierarchical elements with opening and closing tags. This helps with validation and complex structures, but increases verbosity.
Example:
var httpClient = new HttpClient();
var url = "https://httpbin.org/post";
var xml = @"<user>
<name>John Doe</name>
<email>john@email.com</email>
</user>";
var content = new StringContent(xml, Encoding.UTF8, "application/xml");
var response = await httpClient.PostAsync(url, content);
var result = await response.Content.ReadAsStringAsync();
Advantages:
Rich structure with support for attributes, namespaces, and schema validation (DTD/XSD).
Recommended for SOAP-based APIs and legacy systems.
Suitable for domains requiring strong data validation.
Disadvantages:
Verbose and larger in size compared to JSON.
Harder to parse with modern languages like JavaScript.
Losing popularity in modern APIs, which favor JSON for its simplicity.
Conclusion
Choosing the correct Content-Type when sending data in an HTTP request is not just a technical detail—it directly affects compatibility, security, and efficiency in client-server communication. Each type has its ideal use case, and understanding their differences is key to building robust and interoperable APIs.