415 Unsupported Media Type means the server refused the request because the format of the request body is not supported. In most cases, the URL is correct and the server is reachable, but the body format, Content-Type, Content-Encoding, or upload type does not match what the endpoint expects.
This is a request-format problem, not a generic outage. It is especially common in APIs, form submissions, file uploads, webhook integrations, JavaScript requests, and WordPress plugins that send data in the wrong format.
Quick Fix
- Check the request
Content-Typeheader first. - Make sure the request body format matches the header exactly.
- If you send JSON, use
Content-Type: application/json. - If you upload a file, make sure the endpoint accepts that file type and encoding.
- Check whether the server rejects the request because of
Content-Encoding. - Compare the API documentation with the actual request you are sending.
- If this is a form, check whether the form uses the correct
enctype. - If this is WordPress, test plugins, REST API settings, and security layers.
- Check server logs and application logs for the exact rejected media type.
- Review recent API, plugin, framework, or reverse proxy changes first.
What Is 415 Unsupported Media Type?
415 Unsupported Media Type is an HTTP client error response. It means the server understood the request, but refused to process it because the request body was sent in a format that the target resource does not support.
In practical terms, this usually means one of these:
- the request body format is wrong,
- the
Content-Typeheader is wrong or missing, - the
Content-Encodingis wrong, - the endpoint only accepts specific media types,
- the client and server disagree about how the body is encoded.
This is different from similar errors:
- 400 Bad Request often means the request syntax or structure is invalid.
- 405 Method Not Allowed means the HTTP method is not allowed for the resource.
- 406 Not Acceptable is about the response format the client wants.
- 415 Unsupported Media Type is about the request body format the server received.
Typical examples:
- sending JSON with
application/x-www-form-urlencoded, - sending XML to an endpoint that only accepts JSON,
- uploading a file type the server does not allow,
- sending compressed data with the wrong
Content-Encoding, - posting a form without the correct multipart encoding.
Why 415 Unsupported Media Type Happens
Most real cases come from a short list of causes.
1. The Content-Type Header Is Wrong
This is the most common cause.
Typical examples:
- the client sends JSON but labels it as
text/plain, - the client sends JSON but uses
application/x-www-form-urlencoded, - the client sends form data but uses
application/json, - the request body is correct, but the header tells the server to parse it differently.
The body and the declared media type must match.
2. The Content-Type Header Is Missing
Many APIs and application endpoints reject request bodies when the content type is omitted entirely.
This often happens in:
- custom fetch requests,
- backend scripts,
- mobile apps,
- webhooks,
- integration tools that build raw HTTP requests manually.
If the endpoint expects JSON, the server may refuse the body without Content-Type: application/json.
3. The Body Format Does Not Match the Endpoint Contract
An endpoint may accept only one or two media types.
Common examples:
- API accepts JSON only, but the client sends XML,
- upload endpoint expects multipart form-data, but the client sends raw binary,
- form endpoint expects URL-encoded fields, but the client sends JSON.
This is especially common when frontend and backend teams assume different formats.
4. The Content-Encoding Header Is Wrong
415 is not only about Content-Type. It can also happen when the request body encoding is not supported or is declared incorrectly.
Examples:
- the client says the body is compressed but it is not,
- the client uses an unsupported encoding,
- the proxy or library compresses the request but the server does not expect it,
- the body is transformed in transit and the headers no longer match it.
5. File Upload Type Is Not Allowed
Some 415 errors happen during file uploads.
This is common when:
- the file MIME type is not accepted,
- the upload endpoint only accepts images or PDFs,
- the browser or client sends the wrong MIME type,
- security rules reject uncommon file formats.
In these cases, the upload route exists, but the media type is blocked.
6. The Form Uses the Wrong enctype
HTML forms can trigger 415 errors when the form encoding does not match what the server expects.
Common examples:
- file upload form missing
multipart/form-data, - backend expects form fields but receives raw JSON,
- frontend library overrides the browser’s default form behavior.
This is very common in contact forms, admin forms, and file upload widgets.
7. The API Client or JavaScript Request Is Built Incorrectly
Modern apps often send requests through JavaScript, SDKs, or HTTP clients.
415 can happen when:
- headers are hardcoded incorrectly,
- the body is stringified twice,
- the body is sent as an object without the correct header,
- the request library adds a default content type the backend does not accept.
8. Reverse Proxies, WAF Rules, or Security Layers Interfere
Sometimes the app supports the media type, but the proxy or security layer rejects it first.
This often happens because of:
- WAF rules blocking some upload types,
- reverse proxies stripping or rewriting headers,
- security tools rejecting unusual request bodies,
- API gateways only allowing selected media types.
9. WordPress Plugins or REST API Rules Reject the Body
On WordPress sites, 415 can be triggered by:
- REST API restrictions,
- security plugins,
- upload plugins,
- media handling plugins,
- broken AJAX requests,
- caching or optimization plugins altering request flow.
In those cases, the WordPress stack may reject the media type before the request reaches the intended logic.
How to Fix 415 Unsupported Media Type Step by Step
Start with the request itself. Most 415 errors are solved by correcting what the client sends.
1. Check the Exact Content-Type Header
This is the first and most important check.
Make sure it matches the body exactly.
Common valid examples:
application/jsonapplication/x-www-form-urlencodedmultipart/form-datatext/plain- specific API or file media types
If the header and body format do not match, the server may correctly reject the request.
2. Check Whether the Header Is Missing Entirely
If you send a body, do not assume the client sets the header correctly for you.
This is especially important in:
- custom JavaScript fetch calls,
- curl or command-line requests,
- backend integration scripts,
- webhook senders,
- mobile apps.
Some libraries add headers automatically. Some do not.
3. Make Sure the Endpoint Actually Accepts That Format
Check the route or API documentation and confirm what the endpoint expects.
Ask:
- Does it accept JSON?
- Does it accept XML?
- Does it expect multipart uploads?
- Does it require form-encoded fields?
- Does it reject some file types?
The request may be valid in general, but still invalid for that resource.
4. Check Content-Encoding If Compression Is Involved
If the request body is compressed or transformed, verify the encoding headers carefully.
Check for:
- wrong compression declaration,
- unsupported encoding,
- proxy changing the body without updating headers,
- client library enabling compression unexpectedly.
This is more common in APIs, gateways, and automated integrations.
5. Fix Forms and Uploads
If the issue happens in a normal form:
- check the form method,
- check the action URL,
- check the
enctype, - check whether the backend expects file upload handling.
For file uploads, verify:
- allowed MIME types,
- file extension restrictions,
- multipart encoding,
- plugin or API requirements.
6. Check JavaScript or API Client Code
If the issue comes from frontend code or an API client, inspect the exact request being sent.
Look for:
- incorrect header values,
- body being stringified incorrectly,
- double encoding,
- wrong request builder defaults,
- SDK assumptions that do not match the backend.
This is one of the most common causes in modern apps.
7. Check Server Logs and App Logs Together
The server response alone often is not enough.
Check:
- access logs,
- application logs,
- framework logs,
- API gateway logs,
- upload validation logs.
You want to see exactly which media type was rejected and why.
8. Test Without WAF, Proxy, or Security Filters Temporarily
If the app logic looks correct, test whether a security layer is blocking the request.
Focus on:
- WAF rules,
- reverse proxies,
- API gateways,
- WordPress security plugins,
- upload scanning or content validation layers.
If the request works after that, the blocking layer is outside the app itself.
9. Check WordPress Plugins and REST API Behavior
If this is WordPress:
- disable recent plugins,
- test REST API endpoints directly,
- check upload and media settings,
- review security and optimization plugins,
- check whether AJAX or admin routes are being altered.
This is especially important when 415 appears after a plugin update.
10. Review Recent Changes First
This is often the fastest route to the cause.
Ask what changed before 415 started appearing:
- API update,
- frontend rewrite,
- new JavaScript library,
- server config change,
- WordPress plugin update,
- WAF or security hardening,
- file upload restrictions.
Most 415 errors begin right after one of those changes.
Advanced Troubleshooting
Understand the Difference Between Request Media Type and Response Format
This is one of the most important distinctions.
- 415 is about the format of the body you send to the server.
- 406 is about the response format the client says it wants back.
If you mix those up, you may debug the wrong headers.
Check Whether the Server Is Strict About Exact Media Type Syntax
Some servers are stricter than developers expect.
They may reject:
- wrong charset syntax,
- unexpected subtype,
- extra parameters,
- wrong boundary definitions for multipart requests.
Small header mistakes can cause a full 415 response.
Look for Hidden Transformations in the Middle
Sometimes the client sends the right thing, but something in the middle changes it.
Common sources:
- reverse proxies,
- API gateways,
- security scanners,
- serverless adapters,
- middleware that rewrites headers or bodies.
This is why inspecting the exact final request matters so much.
Use Endpoint-Specific Testing
Do not assume all routes behave the same.
Compare:
- one endpoint vs another,
- JSON route vs upload route,
- public API vs admin API,
- browser form vs API client.
Often only one route is misconfigured.
Prevention Tips
- Document required request formats for every API route.
- Keep frontend and backend teams aligned on
Content-Typeexpectations. - Test JSON, form, and upload requests after deployments.
- Review file upload MIME restrictions before production use.
- Be careful with proxy, WAF, and gateway layers that inspect request bodies.
- Use consistent request-building code across apps and integrations.
- Log rejected media types clearly on the server side.
The best prevention is simple: make sure the body format, declared headers, and endpoint expectations all match exactly.
When to Contact Support
Contact your developer or API team if:
- the endpoint contract is unclear,
- the route may not support the expected media type,
- the issue started after backend or frontend deployment.
Contact your hosting provider or server admin if:
- reverse proxy or WAF behavior may be involved,
- uploads are being filtered before reaching the app,
- server configuration changed recently.
Focus on WordPress/plugin troubleshooting if:
- the issue started after a plugin update,
- REST API or AJAX calls are affected,
- uploads fail in WordPress only.
FAQ
What does 415 Unsupported Media Type mean?
It means the server refused the request because the request body format is not supported for that resource.
How do I fix 415 Unsupported Media Type fast?
Check the exact Content-Type header, make sure it matches the body, confirm the endpoint accepts that format, and then review encoding, file type, proxies, security layers, and recent changes.
Can a wrong Content-Type cause a 415 error?
Yes. This is the most common cause. The body and the declared media type must match exactly.
Can file uploads cause 415 Unsupported Media Type?
Yes. If the file MIME type, form encoding, upload route, or security rules do not match what the server accepts, a 415 error can happen.
Can WordPress cause a 415 error?
Yes. WordPress plugins, REST API restrictions, upload settings, security plugins, and broken AJAX requests can all trigger 415 errors.
Final Thoughts
415 Unsupported Media Type usually means the server is reachable and the route exists, but the request body format is wrong for that endpoint. In practice, the most common causes are wrong or missing Content-Type, mismatched body format, unsupported upload type, encoding issues, and security or proxy layers that reject the request.
Start with the request itself first: exact body, exact Content-Type, exact endpoint. Then move through encoding, form handling, upload rules, proxy layers, and recent changes in that order. That path solves most 415 errors much faster than treating them like a generic server failure.