413 Content Too Large
The request body exceeds the size limit the server is willing or able to process for this resource.
Defined in RFC 9110 §15.5.14
What 413 means
413, renamed Content Too Large in RFC 9110, formerly Request Entity Too Large, means the request body exceeds a size limit the server is willing or able to process for this resource. The limit may be a hard architectural constraint or a deliberate policy choice, and RFC 9110 allows the server to optionally include a Retry-After header when the limit is temporary, for example when it's driven by momentarily low disk space rather than a fixed policy.
Limits are enforced at multiple layers that don't always agree: nginx's client_max_body_size, Apache's LimitRequestBody, application framework body-parser limits, and API gateway or CDN caps, such as API Gateway's roughly 10 MB or Cloudflare's tiered limits by plan, can each reject a request before it reaches the next layer. A request that passes the application's own limit can still be rejected by a reverse proxy in front of it, which is a common source of confusing 413s that don't match the limit documented in the application code.
File uploads are the dominant real-world trigger, but oversized JSON or XML payloads, often from embedding a base64-encoded image or document directly in a field rather than uploading it separately, can trigger the same limit on APIs that never expected large binary content in a text payload. Streaming or chunked upload support, and resumable upload protocols for large files, sidestep the problem entirely by never requiring the whole payload in memory or within one request's declared size at once.
Common causes
- A file upload exceeds the configured maximum body size at the application, proxy, or CDN layer.
- A JSON or XML payload embeds large binary data, such as a base64-encoded image, inline instead of uploading it separately.
- The reverse proxy's body size limit, such as nginx's client_max_body_size, is lower than the application's own limit.
- The client sends an entire large file in one request instead of using chunked or resumable upload.
- A temporary server-side constraint, such as low disk space, triggers a lower effective limit than usual.
How to fix a 413
If you are the client (browser user or API caller)
- Compress or reduce the payload size before sending, such as compressing images before upload.
- Use a chunked, multipart, or resumable upload API for large files instead of one large request.
- Check the API documentation for the exact maximum payload size and validate client-side before sending.
If you run the server
- Raise the body size limit consistently across the application, reverse proxy, and CDN or gateway layers so they agree.
- Support streaming or chunked uploads for large payloads instead of requiring the full body in one request.
- Return the exact size limit in the 413 response body so clients can adapt without guessing.
Example
POST /uploads HTTP/1.1
Host: files.example.com
Content-Length: 157286400
[150 MB file body]
HTTP/1.1 413 Content Too Large
Content-Type: application/json
{"error": "payload_too_large", "max_bytes": 52428800, "message": "Maximum upload size is 50MB"}Try it live
Our free status responder returns a real HTTP 413 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/413