HTTP 413 Content Too Large: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, upload tool, or monitoring check receives HTTP 413 Content Too Large.
• The error appears when submitting a large file, form, JSON document, multipart request, or other request body.
• A smaller version of the same request may succeed while the larger request fails.
• The response may come from a proxy, CDN, WAF, web server, or application and may have different headers or body text depending on that layer.
• The rest of the site may remain available, and unrelated URLs or request types may continue to work.
• DNS resolution and TLS can still be healthy because 413 is an HTTP-layer response.

Root causes, ordered by likelihood

1. The request exceeds an upload or body-size limit. The application or web server may enforce a maximum request-body, file, form, or multipart size.
2. An intermediary has a lower limit. A reverse proxy, CDN, load balancer, or WAF can reject the request before the origin application receives it.
3. The request is routed through a stricter endpoint. Different URLs, methods, virtual hosts, or environments may have different size policies.
4. Configuration limits do not match. The proxy may allow a request that the application rejects, or the application may allow one that the proxy blocks.
5. The request is unintentionally larger than expected. Multipart overhead, an oversized encoded field, an attached file, or a client retry with duplicated data can increase the body size.
6. The endpoint intentionally rejects large content. Some APIs or upload routes impose a product or security limit that should not be removed without confirming the intended policy.

How to fix it

For visitors and API users

1. Confirm the exact URL and repeat the request once without repeatedly refreshing it.
2. If you are uploading a file, try a smaller file or reduce the file size using an approved format or compression method.
3. For an API request, compare the failing payload with a minimal valid payload. Check for unexpectedly large fields, embedded data, duplicated content, or an incorrect multipart construction.
4. Confirm that the request uses the intended method and content type. Do not remove authentication or security controls just to bypass the error.
5. If smaller requests work but the required request does not, send the site owner the URL, method, approximate request size, timestamp, response headers, and a sanitized description of the payload. Do not share passwords, cookies, tokens, or API secrets.

For site owners and developers

1. Capture the failing request. Record the URL, HTTP method, content type, approximate body size, status, response headers, and whether the request passes through a proxy, CDN, load balancer, or WAF. Redact credentials and personal data.
2. Reproduce with a size comparison. Test a minimal valid request and progressively larger requests, or compare a successful upload with the failing one. This helps establish the effective limit without changing configuration prematurely.
3. Identify the generating layer. Compare the response body, headers, access logs, proxy logs, WAF events, and application logs for the same timestamp and request. If the request is absent from application logs, an upstream component may have rejected it first.
4. Compare limits along the path. Check the relevant request-body, upload, multipart, proxy, CDN, WAF, and application limits. The effective limit is controlled by the first component that refuses the request.
5. Choose the narrowest correction. If the request should be accepted, adjust only the relevant route or component after confirming authorization, memory, storage, timeout, and security implications. If the limit is intentional, keep it and change the client workflow or document the supported maximum.
6. Retest the original request pattern. Use the same method, URL, content type, and representative payload size. Confirm that an accepted request reaches the application and that malformed or clearly oversized requests remain handled as intended.
7. Check adjacent behavior. Test a smaller request, an unrelated route, authentication behavior, and any other proxy or application tier affected by the configuration change. Keep the change version controlled and record the final limit and reason.

Prevention & how to verify the fix

• Document the supported maximum request, file, and multipart sizes for each upload or API route.
• Keep application, web-server, proxy, CDN, and WAF limits visible and version controlled where possible.
• Test boundary sizes and representative large requests in a non-production environment before release.
• Monitor 413 responses by route, method, client, and deployment so an unexpected increase is distinguishable from an intentional limit.
• Ensure clients validate file and payload size before transmission and provide a clear alternative when a request is too large.
• Retain enough sanitized proxy and application logging to determine which layer rejected a request without recording secrets or unnecessary personal data.

Frequently asked questions