415 Unsupported Media Type 4xx

What does 415 mean?

A 415 Unsupported Media Type response means the server understands the request method and URL, but refuses to process the request body because its format — as indicated by the Content-Type header — isn't one the server supports for this operation. The data itself might even be perfectly well-formed in its own format; the problem is that the server simply doesn't accept that format here.

A common example: sending Content-Type: application/xml with an XML body to an API endpoint that only accepts application/json. The XML might be perfectly valid XML — it's just not a format this endpoint handles.

How a 415 behaves

• It's driven by the Content-Type header of the request — this is the server's primary signal for what format the body is in
• It can carry a body listing the media types the endpoint does support
• It's not cacheable
• It's the inverse of 406 — 415 is about the format of what the client sent; 406 is about the format the client is willing to receive

Common causes

If you're building the API:

• An endpoint is correctly restricted to specific content types (e.g., application/json only), and a client sent something else
• A client sent no Content-Type header at all, and the server requires one to determine how to parse the body
• An endpoint that used to accept multiple formats (JSON and form-encoded, for instance) has been simplified to accept only one, and some clients haven't been updated

If you're calling an API:

• You're sending Content-Type: application/x-www-form-urlencoded (the default for many HTML forms and some HTTP client libraries) to an endpoint that expects application/json
• Your Content-Type header has a typo or unusual casing that the server's parsing doesn't recognize (though most servers handle header casing correctly per HTTP conventions)
• You're sending a file upload with Content-Type: multipart/form-data to an endpoint that expects a raw JSON body, or vice versa

If you're a website visitor:

• Rare to encounter directly — 415 is primarily an API/development concern surfacing from incorrect Content-Type headers in form submissions or API calls, not typical page navigation

How to fix it

As an API/website builder:

• Document supported Content-Type values clearly for each endpoint
• Return a body listing supported media types when rejecting a request with 415 — this directly tells the client what to change
• Consider whether being more permissive (accepting multiple formats, or attempting to parse the body regardless of Content-Type if it's unambiguous) would reduce friction for API consumers, weighing this against the value of stricter validation

As an API consumer:

• Check that your Content-Type header matches what the API expects — application/json for JSON bodies, application/x-www-form-urlencoded for form-encoded data, multipart/form-data for file uploads, etc.
• If using an HTTP client library, verify it's setting the Content-Type header correctly based on how you're constructing the request body — some libraries default to a particular content type that may not match what you intend
• Read the 415 response body if present — it often lists exactly which content types are accepted

As a website visitor:

• Not typically something you can fix directly — if a form on a site is producing this error, it's a site-side bug in how the form's data is being submitted

406 vs 415

Real-world examples

APIs that strictly require application/json for all write operations commonly return 415 if a client sends form-encoded data (application/x-www-form-urlencoded) — a frequent occurrence when developers use generic HTTP client defaults without explicitly setting JSON content types and serializing bodies as JSON. File upload endpoints expecting multipart/form-data will return 415 if a client instead sends raw binary data with a different Content-Type, a common mistake when switching between different upload implementation approaches.

SEO implications

415 is relevant only to API/form-submission request bodies (POST/PUT/PATCH), not regular page navigation, and has no direct SEO implications.

FAQ

What's the difference between 415 and 406?

415 means the server can't process the format of the data the client sent (based on Content-Type). 406 means the server can't produce a response in any format the client said it would accept (based on Accept). They're about opposite directions of the request/response exchange.

My request body looks correct — why am I getting 415?

Check your Content-Type header specifically — even if the body's actual content is well-formed, a Content-Type that doesn't match what the server expects (or that's missing entirely) can trigger 415 regardless of whether the body itself would otherwise be valid.

Does 415 mean my data is invalid?

Not necessarily — the data could be perfectly valid in the format it's in. 415 means that format isn't one this particular endpoint accepts, which is different from the data being malformed or failing validation (that would be 400 or 422).

How do I set the correct Content-Type for a JSON API request?

Most HTTP client libraries provide an option to send JSON directly (which automatically sets Content-Type: application/json), or you can set the header explicitly if constructing the request manually. The header value should match the actual serialization format of the body you're sending.

Can a single endpoint support multiple Content-Type values?

Yes — some APIs are designed to accept multiple formats for the same endpoint (e.g., both JSON and XML, or both JSON and form-encoded), inspecting the Content-Type header to determine how to parse the body accordingly. This is a deliberate design choice that adds flexibility at the cost of additional parsing logic.

Fun fact

415 and 406 form a clean conceptual pair covering both "directions" of format negotiation in HTTP — together they represent the protocol's (largely underused, in modern practice) built-in vocabulary for client and server to negotiate not just whether a request succeeds, but in what format the conversation happens, a feature more relevant in eras when XML, JSON, and various other formats genuinely competed for dominance in API design.