HTTP 415 Unsupported Media Type: Fix Content-Type Errors in APIs

A 415 means the server refuses the request because the body is in a format the endpoint does not support. The decision is made from the Content-Type header (and sometimes Content-Encoding), not from your payload quality. If the format is right and the contents are wrong, you want 400 or 422. See the HTTP 415 reference.

The server may include an Accept header in the 415 response listing the formats it does support, so inspect the response headers before guessing.

If you are a visitor

This is mostly a developer error, but a person using a site may hit it during uploads.

1. Check the file type. Uploading a format the site does not accept (for example a HEIC photo or a .webp image to an older form) can cause it. Convert to JPG, PNG or PDF as the form asks.
2. Rename only after converting. Changing an extension does not change the true type of a file.
3. Try another browser to rule out an extension interfering.
4. Report it with the file type and the page, since the site may be missing a friendly validation message.

If you build or run the service

1. The client sends no or the wrong Content-Type

The most common cause by far. A POST with JSON that uses curl's default sends application/x-www-form-urlencoded, so a JSON-only API says 415.

curl -i -X POST https://api.example.com/items -d '{"name":"x"}'   # fails: wrong declared type

curl -i -X POST https://api.example.com/items \
  -H "Content-Type: application/json" \
  -d '{"name":"x"}'

In JavaScript, fetch needs the header set explicitly when you send a JSON string:

fetch("/items", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "x" })
});

If you pass a FormData object, do not set Content-Type manually, because the browser must add the multipart boundary itself.

2. The endpoint only accepts another type

Read the API contract. Some endpoints take application/x-www-form-urlencoded, multipart/form-data, application/xml or application/octet-stream only. Others require a vendor type such as application/vnd.api+json. Compare against the API docs of the service you call and test the body with the JSON वैलिडेटर if it is meant to be JSON.

3. Charset and parameters

Some strict parsers reject application/json; charset=utf-16 or an unknown parameter. Use application/json (UTF-8 is the default for JSON) and avoid extra parameters unless required.

4. Framework configuration

Frameworks pick handlers by media type, and a missing handler yields 415:

• Spring Boot: a @RequestMapping(consumes = "application/json") method rejects other types, and a missing message converter (for example no XML library) gives "Content type 'application/xml' not supported".
• Express: the body parsers only parse matching types; express.json() ignores non-JSON bodies, which usually shows up as an empty body rather than 415, but custom middleware may reject them.
• ASP.NET Core: [Consumes("application/json")] and input formatters decide; add the formatter you need.
• Laravel and Django REST Framework: DRF returns 415 when no parser class matches ("Unsupported media type ... in request"); check DEFAULT_PARSER_CLASSES.

5. Compressed request bodies

A client that sends Content-Encoding: gzip to a server that does not decompress requests may trigger 415. Disable request compression, or enable decompression on the server.

6. Proxy, CDN or WAF filtering

Firewalls can block types that look unusual, such as text/xml or application/octet-stream, and respond 415 or 403. Compare a request direct to the origin with one through the CDN. Identify who answered using the HTTP Header Checker.

Debugging checklist

1. Capture the exact request with curl -v and note the Content-Type line.
2. Read the 415 response body and Accept headers.
3. Match the type to what the route declares, in code or the docs.
4. If it passes locally but fails in production, compare reverse-proxy settings and request filtering.
5. Re-test through the public hostname with the HTTP स्टेटस चेकर when the endpoint accepts a simple request.

Format your payloads with the JSON फ़ॉर्मेटर and see other helpers under developer tools. Add the API's health URL to an अपटाइम मॉनिटर.

अगले कदम

• Read the HTTP 415 reference.
• Compare with 400 Bad Request.
• See how to monitor API endpoints.
• Inspect request and response headers with the HTTP Header Checker.

सामान्य प्रश्न

Is 415 a client or server error?

It is a client error (4xx): the request used a format the endpoint will not accept. The fix is usually a header or format change on the client, or adding support on the server.

Why does it work in Postman but not in my code?

Postman sets Content-Type for you based on the body mode. Your code may be sending a different header or none.

What is the difference between 415 and 406?

415 is about the format of the request body. 406 is about the response format the client asked for through Accept.

Should I return 415 for unknown fields?

No. Unknown fields in a correctly typed body are a validation matter, so use 400 or 422.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.