413 - Content Too Large
HTTP 413 Content Too Large means the request body exceeds the size limit accepted by the server.
Last reviewed: April 16, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Content Too Large Mean?
A server, edge, or gateway refused to process the request because the body exceeded the size it is willing or able to accept. This is usually a request-shape and limit-alignment problem, not a backend latency problem.
Common Causes
- -Nginx client_max_body_size remains 1m while frontend now uploads 8 MB multipart images.
- -Gateway parser limit is 10 MB but base64 expansion inflates binary payload beyond accepted threshold.
- -WAF request-body inspection cap is exceeded, and oversized payload is blocked before application parsing.
- -Clients send large arrays, audit blobs, or trace dumps to a JSON endpoint that was designed for small control-plane requests.
- -One hop in the path enforces a smaller body limit than the documented API contract, so 413 appears only in production ingress.
How to Fix Content Too Large
- 1Measure the serialized payload after encoding so you know the real byte size crossing each hop.
- 2Move large binaries or bulk bodies to resumable, multipart, or object-storage upload flows instead of forcing them through JSON APIs.
- 3Align body-size limits across CDN, gateway, reverse proxy, and origin so the first rejection boundary is intentional.
- 4Use
Expect: 100-continuefor large uploads so a server can reject early before the full body is sent. - 5Honor
Retry-Afteronly when the server signals a temporary limit condition; otherwise retrying the same oversized body will fail again.
Step-by-Step Diagnosis for Content Too Large
- 1Capture actual payload byte size at client, edge, and origin to locate exactly where rejection occurs.
- 2Compare configured size limits across every hop in the request path, including WAF and parser caps.
- 3Identify growth drivers such as base64 inflation, unbounded arrays, large multipart parts, or duplicated metadata.
- 4Retest with payloads just below and just above the threshold to validate the real rejection boundary.
- 5Check whether the server includes
Retry-Afterto distinguish a temporary capacity constraint from a hard limit.
Seen in Production
- -A mobile app sends a 9 MB image as base64 JSON, inflating the body past a 10 MB gateway cap and returning 413 before the API handler runs.
- -An ingress proxy enforces 5 MB while the origin accepts 25 MB, so 413 appears only in production behind the edge tier.
- -A browser uploads a large multipart form without
Expect: 100-continue, so users spend time sending the full body only to be rejected at the edge. - -A diagnostics endpoint starts receiving huge trace or log bundles after a frontend change, and the request shape silently outgrows the route budget.
Encoded Size and Body Composition Audit
- -Measure serialized byte size after encoding (example: base64 attachment increases payload by roughly one third and crosses a 10 MB limit).
- -Inspect request composition for unbounded fields (example: client sends full history array instead of incremental delta).
Edge-to-Origin Limit Ladder
- -Audit all size caps in path order (example: CDN 8 MB, API gateway 10 MB, origin 20 MB still yields edge rejection at 8 MB).
- -Validate upload-path fit (example: switch large media from JSON POST to resumable multipart upload endpoint).
Decision Shortcut: Hard Cap vs Wrong Upload Path
- -If the same body always fails at nearly the same byte count, prioritize deterministic limit boundaries before debugging server latency.
- -If the body only becomes too large after encoding or attachment wrapping, redesign the payload shape instead of only raising one proxy cap.
- -If the endpoint is really for metadata, stop forcing bulk binary transfer through it and move the upload to an object-storage or multipart flow.
Wrong Fix to Avoid
- -Do not keep retrying the same oversized request unless the server explicitly signals a temporary condition with
Retry-After. - -Do not raise one proxy limit in isolation if another hop still rejects the same payload earlier in the path.
- -Do not treat 413 like a generic timeout or availability issue when the body shape itself is already outside the contract.
Implementation Examples
2026-04-16T11:44:18Z edge=api-gateway requestId=req_91aa4c
contentLength=12582912 limitBytes=10485760 status=413
message="request body exceeds configured maximum before upstream forwarding"curl --http1.1 --expect100-timeout 2 \
-H 'Expect: 100-continue' \
--data-binary @payload.bin \
https://api.example.com/uploadsclient_max_body_size 10m;
client_body_buffer_size 256k;Incident Timeline
11:42 UTC
A request body grows beyond the intended contract
Signal: An upload flow, base64 wrapper, or unbounded JSON field pushes the serialized body near or beyond a hidden size ceiling.
Why it matters: The first useful question is how large the request became after encoding, not whether the backend was slow.
11:44 UTC
One hop rejects the body before normal application handling
Signal: Edge, WAF, gateway, or parser returns 413 while the downstream application never sees the full payload.
Why it matters: At this point the incident is about body size and path alignment, not business logic.
11:45 UTC
Blind retries resend the same oversized payload
Signal: Clients immediately replay the same body and hit the same 413 boundary with no progress.
Why it matters: A 413 incident does not clear until the payload shape, upload path, or configured limit changes.
11:53 UTC
The upload path is corrected and bodies complete successfully
Signal: Clients move to resumable upload, body size falls under the documented limit, or the intended hop limits are aligned.
Why it matters: That confirms the real fix lived in request design and size-boundary control rather than backend tuning.
Seen in Production
Mobile app sends large base64 media in JSON body
Frequency: common
Example: Client uploads a 12 MB image as base64 JSON to an endpoint limited to 10 MB and receives 413 before the API handler sees the full body.
Fix: Move media uploads to dedicated object storage flow and submit only metadata to API.
One proxy tier has a lower body limit than the documented API
Frequency: common
Example: Origin allows 25 MB, but ingress proxy enforces 5 MB, causing 413 only in the production ingress path.
Fix: Standardize size policies across ingress tiers and add config-conformance checks in the deployment pipeline.
Diagnostics or audit payloads silently outgrow a control-plane endpoint
Frequency: medium
Example: A route designed for small JSON metadata starts receiving huge trace bundles after a frontend change and begins returning 413.
Fix: Cap request shape at the client and move bulk payloads to a storage-backed upload path.
Wrong Fix vs Better Fix
Raise one proxy cap vs align the whole limit ladder
Wrong fix: Increase a single ingress limit and assume the incident is solved.
Better fix: Trace every body-size ceiling from edge to origin and make the first rejection boundary intentional.
Why this is better: A larger limit on one hop does not help if another tier still rejects the same payload earlier or later in the path.
Retry the same body vs redesign the upload path
Wrong fix: Resend the same oversized request until it eventually gets through.
Better fix: Shrink the payload, switch to resumable or multipart upload, or move bulk data to object storage.
Why this is better: A deterministic body-size violation will fail forever until the request shape or allowed limit changes.
Debug backend latency vs measure encoded body size
Wrong fix: Treat 413 like a slow backend incident and start tuning response time.
Better fix: Measure serialized body size, locate the rejecting hop, and prove whether encoding or attachments pushed the request over the limit.
Why this is better: 413 is about what the server is willing or able to accept, not how long the application needs to respond.
Debugging Tools
- -curl --trace-ascii for raw request framing
- -Body-size and content-length logs at the rejecting hop
- -Ingress proxy limit logs
- -Framework parser debug mode
- -Payload schema and boundary-size tests
How to Verify the Fix
- -Resubmit with expected payload sizes and confirm 413 is cleared for supported limits.
- -Run boundary tests around maximum body size to ensure deterministic behavior.
- -Verify large-upload user flows complete without hidden truncation, early proxy rejection, or object-storage handoff regressions.
- -Confirm
Retry-Afterhandling is respected only for endpoints that intentionally use temporary 413 responses.
How to Prevent Recurrence
- -Publish explicit per-endpoint size limits and enforce them in SDK/client validators.
- -Add contract tests for maximum payload boundaries and multipart upload paths.
- -Track payload-size percentiles in observability dashboards to catch drift early.
- -Prefer
Expect: 100-continue, multipart, or resumable flows for large bodies so rejections happen before full upload cost is paid.
Pro Tip
- -store rolling p95/p99 request-body size by endpoint and alert before values approach hard limits, not after 413 spikes start.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.