413 vs 431: Content Too Large vs Request Header Fields Too Large
413 and 431 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 413 — Content Too Large | HTTP 431 — Request Header Fields Too Large |
|---|---|---|
| Definition | Content Too Large describes how the server processed the request and what the client should do next. | Request Header Fields Too Large describes how the server processed the request and what the client should do next. |
| Plain-language summary | The request body is larger than the server is willing to process. The server may close the connection or include a Retry-After header if the limitation is temporary. | The server refuses the request because the request headers (either individually or cumulatively) are too large. Common causes include cookie bloat, very long Authorization tokens, or large custom headers. |
| When to use | Servers return this automatically when the request body exceeds configured limits. As an API designer, set reasonable limits and document them. Include the limit in your error response body. Use Retry-After if the limit is temporary (e.g., rate-limited upload window). | Servers return this automatically when headers exceed configured limits. As an API designer, document header size limits. As an application developer, monitor cookie size and Authorization header lengths. |
| Client behavior | Split the payload into smaller chunks if the API supports chunked uploads. Reduce payload size and retry. | Reduce header size: clear old cookies, shorten tokens if possible, remove unnecessary custom headers, and retry. |
| Caching behavior | Not cached. | Not cached. |
| SEO / crawler impact | Search crawlers interpret 413 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 431 (client-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 413 expect Content Too Large semantics. | API clients branching on 431 expect Request Header Fields Too Large semantics. |
| Safe to retry? | Only after fixing the underlying cause | Only after fixing the underlying cause |
Common real-world scenarios
When you see HTTP 413
Common in file upload APIs, image processing services, and data import endpoints. Spikes indicate clients are sending unexpectedly large payloads — check for un-compressed uploads or clients ignoring the documented size limit.
When you see HTTP 431
Most commonly caused by: cookie accumulation over time (many Set-Cookie calls with short expiry creating a large Cookie header), very long JWT tokens containing large payloads, or header injection bugs that append values repeatedly.
Decision rule
Use 413 when the response should communicate content too large behavior; use 431 when request header fields too large is the accurate protocol signal.
A frequent mistake is swapping 413 and 431 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 413 when the correct protocol signal is Content Too Large. Use 431 when the correct signal is Request Header Fields Too Large. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 413 and 431?
413 communicates Content Too Large, while 431 communicates Request Header Fields Too Large. Choosing the right one keeps clients and intermediaries predictable.
Do 413 and 431 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 413 instead of 431?
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 413 Content Too Large — full guide · HTTP 431 Request Header Fields Too Large — full guide · HTTP 431 status reference · All comparisons · HTTP 413 status reference