Content Types and Encoding

What a media type is

A request or response body is, at the wire level, just a stream of bytes with no inherent meaning. The Content-Type header — a media type, sometimes still called a MIME type — is what tells the other side how to interpret those bytes. application/json means parse them as JSON; text/csv means treat them as comma-separated values; application/pdf means a document.

Without the right media type declared, the receiver is left guessing, and guessing tends to fail in confusing ways. Set Content-Type on every request that carries a body, and read it on every response, so you always know how to handle what came back rather than assuming a format that may not match. It is a small header that prevents a whole class of misinterpretation bugs.

Declaring what you send and want

Two headers carry this conversation between client and server. Content-Type describes the format of the body you are sending right now; Accept states the formats you are able to handle in the response. For a typical JSON API you set both to application/json and move on.

Content-Type: application/json; charset=utf-8
Accept: application/json

Mismatches here cause trouble that looks mysterious until you spot the header. Sending JSON without declaring it can trigger 415 Unsupported Media Type, while asking via Accept for a format the server cannot produce may return 406 Not Acceptable. Matching both headers to what is actually true avoids both errors, and they are among the easiest API problems to fix once you know where to look.

Character encoding

Encoding is the mapping from characters to bytes, and the modern default everywhere is UTF-8, which can represent essentially every character you are ever likely to need — accents, currency symbols, emoji, and non-Latin scripts alike — in a single consistent scheme. Use it uniformly, from your source files all the way through to the bytes on the wire.

Mismatched encodings produce the classic garbled text known as mojibake, where an accented letter turns into a little string of unrelated symbols and a name becomes unreadable. Declaring charset=utf-8 where appropriate and ensuring every layer of your tooling reads and writes UTF-8 keeps text intact across the entire round trip, so what you send is exactly what the other side stores and shows.

Other body formats

JSON dominates modern APIs, but you will still meet other body formats and should recognise them. application/x-www-form-urlencoded encodes key-value pairs the way a classic HTML form submission does. multipart/form-data is the format used for file uploads, where each part can carry its own headers. text/csv turns up frequently in bulk exports and imports of tabular data.

Each of these carries a different internal structure, so you must set the matching Content-Type and build the body to suit it. An endpoint almost always documents exactly which formats it accepts for a given request, and sending the wrong one is a common, entirely avoidable error that surfaces as a puzzling rejection rather than a clear message about format.

Compression

Responses can be compressed in transit to save bandwidth, which matters most on large payloads and slow connections. By sending Accept-Encoding: gzip on your request, you tell the server it may return a gzipped body, which it then signals back to you with Content-Encoding: gzip so you know to decompress it. Most HTTP clients negotiate and handle this transparently, so you simply enjoy smaller, faster transfers without writing any extra code.

For how these content headers sit among the others on a request — authentication, caching, and the rest — read request and response headers, which gives the wider picture of the metadata travelling with every call.