415 vs 422: Unsupported Media Type vs Unprocessable Content
415 and 422 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 415 — Unsupported Media Type | HTTP 422 — Unprocessable Content |
|---|---|---|
| Definition | Unsupported Media Type describes how the server processed the request and what the client should do next. | The server understands the Content-Type and the request is well-formed, but cannot process it due to semantic errors. Common in REST API validation failures. |
| Plain-language summary | The server refuses the request because the Content-Type of the body is in a format the endpoint does not support. The Accept-Post header in the response tells the client what content types are acceptable. | The request body is syntactically valid (it parsed successfully) but semantically invalid — the content violates business rules or data constraints. The most common use is REST API field validation failures. |
| When to use | Return 415 when the Content-Type header specifies a format the endpoint cannot handle. Include Accept-Post or Accept-Patch in the response listing the supported content types. | Return 422 when the body was parsed correctly but failed validation: required field present but empty, value out of allowed range, date in the past when future is required, or custom business rule violation. Use 400 for parsing failures (malformed JSON, wrong Content-Type). Use 409 for conflicts with existing resource state. |
| Client behavior | Change the Content-Type header and re-serialize the body in the supported format before retrying. | Do not auto-retry. Fix the payload based on the validation errors in the response body. Implement client-side validation to prevent 422s before the request is sent. |
| Caching behavior | Not cached. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 415 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 422 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 415 expect Unsupported Media Type semantics. | API clients branching on 422 expect Unprocessable Content semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 415
Common when clients send form-encoded data to endpoints expecting JSON, or send JSON to endpoints expecting XML. Also appears when API versioning changes the required content type.
When you see HTTP 422
In form-heavy APIs, high 422 rates indicate: poor client-side validation that lets invalid data reach the server, mismatch between frontend and backend validation rules, or an API schema change that old clients have not adopted.
Decision rule
Use 415 when the response should communicate unsupported media type behavior; use 422 when unprocessable content is the accurate protocol signal.
A frequent mistake is swapping 415 and 422 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 415 when the correct protocol signal is Unsupported Media Type. Use 422 when the correct signal is Unprocessable Content. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 415 and 422?
415 communicates Unsupported Media Type, while 422 communicates Unprocessable Content. Choosing the right one keeps clients and intermediaries predictable.
Do 415 and 422 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 415 instead of 422?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 415 Unsupported Media Type — full guide · HTTP 422 Unprocessable Content — full guide · All comparisons · HTTP 415 status reference · HTTP 422 status reference