API Content-Type and Accept Header Explainer and Fix Checklist Generator
Fix API body-format bugs by checking Content-Type, Accept, request method, body type, client library and status code. Generate correct headers, cURL examples, JavaScript fetch examples, 415 and 406 debugging notes, CORS reminders and a copyable API request checklist.
- Choose the body format.
- Generate correct headers.
- Compare cURL, fetch, Axios and PHP notes.
- Copy a debugging checklist.
Build correct API Content-Type and Accept headers
Select your request method, body type, current header, expected response and error clue. This tool generates the right request headers, examples and fix notes.
Your header explanation will appear here
Choose the API body type and generate a Content-Type / Accept fix checklist.
What this API Content-Type and Accept header tool does
API request bugs often look bigger than they really are. A backend may return 415 Unsupported Media Type, 400 Bad Request, 422 Validation Error, empty request body, JSON parse error, or 406 Not Acceptable simply because the request headers do not match the actual body. The most common mismatch is sending JSON while forgetting Content-Type: application/json, sending a JavaScript object without JSON.stringify, manually setting multipart boundaries, or asking for the wrong response format with the Accept header.
This tool helps you build the request correctly. Choose the method, body type, current Content-Type, expected Accept header, client type and error clue. The generator creates the correct request headers, cURL command, JavaScript fetch example, Axios-style notes, debugging checklist and API documentation text.
The tool does not call your API. It does not validate your real server. It gives you a clean request contract so you can compare what you are sending with what the backend expects.
Content-Type describes the body you are sending. Accept describes the response format you want back.
Common Content-Type and Accept combinations
| Request body | Content-Type to send | Common mistake |
|---|---|---|
| JSON object | application/json | Sending a raw object in fetch without JSON.stringify, or missing the header. |
| Classic form fields | application/x-www-form-urlencoded | Sending JSON to an endpoint that expects form fields. |
| File upload | multipart/form-data | Manually setting multipart Content-Type and breaking the boundary. |
| Plain text | text/plain | Sending text to an endpoint that expects JSON. |
| XML | application/xml or text/xml | Sending XML to a JSON-only API. |
| No body | No Content-Type needed | Adding Content-Type to GET requests and confusing debugging. |
Why 415 Unsupported Media Type happens
A 415 response usually means the server refuses to process the request body because the media type is not supported for that endpoint. The backend may expect JSON, but the client sends form data. The backend may expect multipart upload, but the client sends raw JSON. The backend may expect application/json, but fetch sends text/plain;charset=UTF-8 because the body was passed incorrectly.
Broken JSON request idea:
Content-Type: text/plain
[object Object]
Better JSON request:
Content-Type: application/json
Accept: application/json
{
"name": "Sagar",
"email": "sagar@example.com"
}
For deeper status-code explanations, use the HTTP Status Code Debugging Helper. If the server returns a JSON error body, use the API Error Response Explainer and Debug Checklist.
Content-Type versus Accept
Content-Type and Accept solve different problems. Content-Type tells the server what you are sending. Accept tells the server what you want back. If you send JSON, use Content-Type: application/json. If you want JSON back, use Accept: application/json. Many APIs work best when you send both.
A 406 Not Acceptable response can happen when the server cannot return a representation that matches the Accept header. For example, if the client says it only accepts XML but the API can only return JSON, the server may reject the response negotiation. In API work, Accept: application/json or Accept: */* is often enough unless the API docs say otherwise.
Fetch and Axios body mistakes
With browser fetch, JSON bodies should usually be stringified manually. Passing a JavaScript object directly can send the wrong body. With Axios, JSON is often handled automatically, but issues still happen when headers are overridden, interceptors change the request, or a FormData upload is treated like JSON.
Fetch JSON pattern:
fetch("/api/users", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Accept": "application/json"
},
body: JSON.stringify({
name: "Sagar"
})
});
For file uploads with FormData in the browser, do not manually set the multipart boundary. Let the browser set the correct multipart Content-Type with the boundary. Manually typing multipart/form-data can break uploads because the server needs the boundary value to parse the parts.
Content-Type and CORS preflight
Some Content-Type values can also affect CORS behavior. JSON requests from browser JavaScript commonly trigger a preflight request. That means the server must handle OPTIONS and allow the headers that the browser wants to send, including Content-Type and Authorization when used. This is why a request may work from Postman but fail from React or browser fetch.
When debugging browser requests, check the Network tab. Look for an OPTIONS request before the real request. If the OPTIONS request fails, fix CORS first. If OPTIONS succeeds and the actual request returns 415 or 422, then debug Content-Type, request body and backend validation.
Related CodeZips tools
FAQ
What does Content-Type mean in an API request?
Content-Type tells the server what format the request body is using, such as JSON, form URL-encoded data, multipart form data, plain text or XML.
What does Accept mean in an API request?
Accept tells the server what response formats the client can understand. For many REST APIs, Accept: application/json is the expected value.
Why do I get 415 Unsupported Media Type?
It usually means the request body format or Content-Type header does not match what the endpoint accepts. For example, the endpoint expects JSON but receives form data or plain text.
Why does my server receive an empty body?
The body may not be stringified, the Content-Type may be wrong, the backend body parser may not be enabled, or the client may be sending data in a format the server is not configured to read.
Should GET requests have Content-Type?
Usually no. GET requests normally do not send a body, so Content-Type is usually unnecessary. Use query parameters for GET filters unless the API docs say otherwise.
Should I manually set multipart/form-data in fetch?
Usually no when using FormData in the browser. Let the browser set the multipart Content-Type and boundary automatically.
Why does application/json trigger CORS preflight?
Browser JSON requests commonly require a preflight check. The server must handle OPTIONS and allow headers such as Content-Type and Authorization when needed.
What is 406 Not Acceptable?
406 can mean the server cannot return a response format that matches the Accept header. Check whether the API can return the format you requested.
Can this tool test my real API?
No. It generates headers, request examples and checklists. Test your real API separately with cURL, Postman, browser fetch, PHP or your app.
Does this tool upload my request body?
No. It runs in your browser. Your endpoint, request body, error message and generated output are processed locally by the page.
Final practical note
When API body bugs feel confusing, reduce the problem to one question: what exact body format am I sending, and what exact format does the endpoint expect? Once Content-Type, Accept, body serialization and backend parser settings match, many 400, 415 and 422 errors become much easier to fix.
