HTTP 415 Unsupported Media Type – Free, Online, Private

What HTTP 415 means

415 says the server refuses the request because the body's media type is not supported for this resource and method. The JSON endpoint received XML, or a required Content-Type was missing and the server will not sniff. The body was not necessarily invalid. It was the wrong kind. Accept, which is about the response, is a 406 problem instead.

415 Unsupported Media Type belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 415

When you see HTTP 415 Unsupported Media Type, stop on that exact status line. 415 Unsupported Media Type means the request body's Content-Type is not accepted. The trace that usually produces it: A client posted JSON and forgot Content-Type: application/json. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 415 when Content-Type is missing or not one of the types you implement for this method. List the types you do accept in the body. Use 400 when the type was right and the contents were wrong. Use 406 when the response type is the problem. Do not sniff a random type and hope.

How to fix HTTP 415

To fix HTTP 415, change the condition that made the server choose Unsupported Media Type. Set Content-Type to a type the server listed and resend. Do not retry without a change. If you were sending a file, confirm the multipart format, not just the filename. Retry once with a supported Content-Type. Retrying the unsupported type will fail. If the log line is a different code, leave this page. The mix-up people make with 415 is this one: 406 is about Accept and the response. 400 is a body you tried to parse and could not. 415 is a type you refuse to parse.

• A client sent text/plain that happened to contain JSON.
• The charset parameter caused a strict match to fail.
• A file upload used the wrong multipart type and the server rejected it before reading the file.

An access log that only stores 415 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 415 Unsupported Media TypeHTTP/1.1 415 Unsupported Media Type
Accept-Post: application/json
Content-Type: application/json

{"accepted":["application/json"]}

Accept-Post is optional and names types the POST target accepts. The body repeats them for clients that do not read that header. The client retries with the right Content-Type. It does not change the bytes if the bytes were already JSON. It changes the header.

What the client should do

Set Content-Type to a type the server listed and resend. Do not retry without a change. If you were sending a file, confirm the multipart format, not just the filename.

Do not cache 415 as the resource. It describes one request.

Retry once with a supported Content-Type. Retrying the unsupported type will fail.

Codes people confuse with HTTP 415

406 is about Accept and the response. 400 is a body you tried to parse and could not. 415 is a type you refuse to parse.