HTTP Request Headers Every Developer Should Know

Request headers are the metadata your client sends alongside every HTTP request. Get them right and APIs just work; get them wrong and you'll chase 401s, 415s, and mysterious CORS failures.

The headers you'll use constantly

• Authorization — credentials. Two common schemes: Basic <base64(user:pass)> and Bearer <token> for OAuth/JWT.
• Content-Type — the media type of the body you're sending, e.g. application/json. A mismatch here causes most 415 and parsing errors.
• Accept — the media type you want back, e.g. application/json. Servers that do content negotiation use it to decide the response format.
• User-Agent — identifies the client. Some APIs reject requests without a recognizable one.
• Cache-Control — controls caching behavior, e.g. no-cache.

Content-Type vs. Accept

These are frequently confused. Content-Type describes the request body; Accept describes the desired response. A JSON API call typically sets both to application/json — but they answer different questions.

The same request, three ways

Once you've got the method, URL, and headers, you'll often need them in different formats. A raw request block:

POST /v1/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

The same thing as curl:

curl -X POST 'https://api.example.com/v1/users' \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer <token>'

And as fetch():

fetch('https://api.example.com/v1/users', {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
    'Authorization': 'Bearer <token>',
  },
})

Build them once, export anywhere

Re-typing headers across a terminal, a REST client, and your code is where quoting bugs creep in. The HTTP Header Builder lets you enter method, URL, and headers once and copy the result as a raw request, curl, or fetch. When you're on the receiving end and need to make sense of a response's headers, the HTTP Header Parser breaks them down.