Content-Type vs Accept Header

Content-Type and Accept are two of the most commonly confused HTTP headers. They look similar, often have the same value (application/json), and both deal with data formats — but they serve completely different purposes. Confusing them causes broken API requests, 400 errors, and hours of debugging. This guide clarifies exactly what each header does, when to use them, and how they work together in HTTP content negotiation.

The One-Sentence Difference

Real-World Analogy: The Restaurant

Imagine ordering at a restaurant:

Content-Type vs Accept: Complete Comparison

What Is the Content-Type Header?

The Content-Type header describes the format (MIME type) of the data in the HTTP message body. It answers the question: "What format is this data in?" — so the recipient knows how to parse it.

Content-Type is unique because it appears in both requests and responses:

• In requests: Tells the server what format the request body is in. "I'm sending you JSON, so use your JSON parser."
• In responses: Tells the browser/client what format the response body is in. "This response is HTML, so render it as a page."

Without Content-Type, the server has no reliable way to know whether you sent JSON, XML, form data, or a binary file. It would have to guess — and guessing leads to parsing failures. This is why most 400 Bad Request errors in APIs are caused by a missing or incorrect Content-Type header.

Content-Type in Requests

When you send a POST, PUT, or PATCH request with a body, Content-Type tells the server how to read that body. The server's middleware (like Express's express.json()) looks at Content-Type to decide which parser to activate:

// JSON body → server activates JSON parser
Content-Type: application/json
Body: {"name": "Alice", "age": 30}

// Form data → server activates URL-encoded parser
Content-Type: application/x-www-form-urlencoded
Body: name=Alice&age=30

// File upload → server activates multipart parser
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
Body: [binary file data split by boundary]

Content-Type in Responses

In server responses, Content-Type tells the browser how to handle what it received. This determines whether the browser renders HTML, parses JSON, displays an image, or triggers a file download:

Content-Type: text/html; charset=utf-8      → Browser renders as web page
Content-Type: application/json               → Browser/JS parses as JSON object
Content-Type: image/png                      → Browser displays as image
Content-Type: application/pdf                → Browser opens PDF viewer or downloads
Content-Type: text/css                       → Browser applies as stylesheet
Content-Type: application/javascript         → Browser executes as script

If Content-Type is wrong in a response, things break visibly. A JSON API that returns Content-Type: text/html will cause fetch().json() to fail. An HTML page served as application/octet-stream will trigger a download instead of rendering.

What Is the Accept Header?

The Accept header is a request-only header that tells the server what response format the client prefers. It answers: "When you send me the response, please use this format."

Unlike Content-Type (which describes data already being sent), Accept describes data the client wants to receive in the future — it's a preference, not a description of current content.

Accept is critical for APIs that support multiple response formats. A single endpoint like /api/users might return JSON (for JavaScript clients), XML (for legacy systems), or CSV (for spreadsheet exports) — the Accept header determines which format the server chooses.

Accept with Quality Values

The Accept header supports quality values (q=0 to q=1) that indicate preference order. Higher q values mean higher preference. No q value means q=1 (highest):

// "I prefer JSON, but I'll accept HTML or plain text"
Accept: application/json, text/html;q=0.9, text/plain;q=0.8

// Breakdown:
// application/json     → q=1.0 (default, highest priority)
// text/html            → q=0.9 (second choice)
// text/plain           → q=0.8 (third choice)

// "I accept anything"
Accept: */*

// "I want images, preferring PNG over JPEG"
Accept: image/png, image/jpeg;q=0.8, image/*;q=0.5

What Browsers Send Automatically

Browsers set Accept headers automatically based on the type of request:

Notice that browsers prefer modern image formats (avif, webp) over older ones. This is content negotiation in action — the server can return WebP to modern browsers while serving PNG to older ones, all from the same URL.

Content-Type in File Uploads

File uploads are where Content-Type gets tricky. The most common mistake developers make is manually setting Content-Type for FormData — which actually breaks the upload.

How multipart/form-data Works

When you upload a file, the request body is split into multiple "parts" separated by a unique boundary string. Each part has its own Content-Type (the file's type) and Content-Disposition (the field name). The overall request Content-Type must include this boundary for the server to know where each part begins and ends.

// What the browser actually sends for a file upload:
POST /api/upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="name"

Alice
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="avatar"; filename="photo.jpg"
Content-Type: image/jpeg

[binary JPEG data here]
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The boundary is randomly generated by the browser. If you manually set Content-Type: multipart/form-data without the boundary, the server cannot parse the parts and the upload fails silently. This is why you should never set Content-Type manually when using FormData — let the browser handle it.

Common MIME Types

Both headers use MIME types as values. Here are the ones you'll encounter daily:

How Content Negotiation Works

Content negotiation is the process where client and server agree on a response format:

The q value (0-1) in Accept indicates preference. application/json without q defaults to q=1 (highest priority). text/html;q=0.9 means "I prefer JSON but HTML is acceptable too."

Practical Code Examples

Fetch API — Sending JSON

// POST JSON to an API
const response = await fetch("https://api.example.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",   // ← I'm SENDING JSON
    "Accept": "application/json"          // ← I want to RECEIVE JSON
  },
  body: JSON.stringify({ name: "Alice", email: "alice@example.com" })
})

// GET request — only Accept needed (no body = no Content-Type)
const user = await fetch("https://api.example.com/users/1", {
  headers: {
    "Accept": "application/json"  // ← Only Accept (GET has no body)
    // No Content-Type needed — GET requests have no body!
  }
})

Fetch API — File Upload

// File upload with FormData
const formData = new FormData()
formData.append("avatar", fileInput.files[0])
formData.append("name", "Alice")

const response = await fetch("/api/upload", {
  method: "POST",
  // ⚠️ Do NOT set Content-Type manually for FormData!
  // The browser sets it automatically with the correct boundary
  headers: {
    "Accept": "application/json"  // ← I want JSON response
  },
  body: formData
})

// ❌ Common mistake:
// headers: { "Content-Type": "multipart/form-data" }  
// This BREAKS file uploads — browser needs to set the boundary itself

Axios

// Axios sets Content-Type: application/json automatically for objects
const { data } = await axios.post("/api/users", {
  name: "Alice",
  email: "alice@example.com"
})
// Axios adds: Content-Type: application/json (automatic)
// Axios adds: Accept: application/json, text/plain, */* (default)

// Explicit headers
const { data } = await axios.get("/api/users/1", {
  headers: {
    "Accept": "application/json"
  }
})

cURL

# POST JSON with both headers
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name": "Alice"}'

# GET with Accept only
curl -H "Accept: application/json" https://api.example.com/users/1

# File upload — curl sets Content-Type automatically with -F
curl -X POST https://api.example.com/upload \
  -H "Accept: application/json" \
  -F "avatar=@photo.jpg" \
  -F "name=Alice"

Common Developer Mistakes

Quick Reference: When to Use Each Header

Best Practices

Interview Questions

Frequently Asked Questions

Related Articles & Tools