The short version
- 01Check which request formats the exact endpoint accepts.
- 02Set Content-Type to describe the body that the client actually sends.
- 03Serialize or convert the body into a supported format rather than changing only its label.
- 04Check Content-Encoding when the request body is compressed.
- 05Let the browser set Content-Type and its boundary when sending FormData.
- 06Retest a minimal supported request before restoring optional fields or attachments.
Raw message
415 Unsupported Media Type
Likely causes
- The endpoint expects a different media type from the one sent.
- Content-Type is missing or does not describe the actual body.
- The request uses a content encoding the server cannot handle.
- A manually set multipart header omits the browser-generated boundary.
The format must be supported and accurately labelled
415 concerns the format of the request content. Rejection can follow Content-Type, Content-Encoding or inspection of the body itself. Correcting field values is a different task from supplying a format the endpoint can read.
Content-Type describes what you are sending, such as application/json. Content-Encoding describes a transformation such as gzip. A body labelled as JSON does not become JSON, and a gzip label requires bytes encoded accordingly.
If a site's upload or form fails
Check the allowed file formats and export a supported copy from the original application where possible. Renaming a file's extension changes its name, not its underlying format. Keep the original until the site accepts and correctly reads the converted copy.
Our diagnostic recommendation is to report the file type and action if the site's own interface rejects a format it advertises as supported. The owner may need to correct request headers or server handling. A 415 does not establish that the file is too large; that is the separate 413 branch.
If you send JSON or multipart form data
Match the body serializer and media type to the endpoint contract. A JSON endpoint may reject form-encoded data even when the same field names appear. Inspect the transmitted body and header together instead of changing Content-Type until the status changes.
For browser FormData sent with fetch or XMLHttpRequest, do not manually set Content-Type. The browser adds the multipart boundary that separates the fields and files. A header set to multipart/form-data without the matching boundary can prevent the server from reading the body; the exact error code depends on the server.
If compression is involved, verify the Content-Encoding declaration and whether the server supports that coding. Reproduce with a minimal supported payload first, then add the original fields and attachment. A later validation error means there is another condition to address, not that format checks were pointless.
Sources and review notes
Checked on . Based on MDN's HTTP header, status and browser FormData documentation. Conversion and minimal-payload comparisons are editorial guidance; endpoints may report multipart failures with different status codes.