413 - Content Too Large
HTTP 413 Content Too Large means the request body exceeds the size limit accepted by the server.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does Content Too Large Mean?
Payload transfer was refused because it exceeded configured size limits, so uploads fail before application-level processing can safely continue.
Common Causes
- -Uploaded file or JSON payload exceeds server body limit.
- -Gateway and origin size limits are lower than client assumptions.
- -Batch request groups too many items into a single payload.
How to Fix Content Too Large
- 1Reduce payload size (compress, chunk, paginate, or move bulk data to object storage upload flows).
- 2Align body-size limits across CDN, gateway, reverse proxy, and origin to remove conflicting ceilings.
- 3If limit exceedance is temporary, honor `Retry-After` when provided and retry with controlled backoff.
Step-by-Step Diagnosis for Content Too Large
- 1Capture actual payload byte size at client, edge, and origin to locate where rejection occurs.
- 2Compare configured size limits across all hops in the request path.
- 3Identify growth drivers in request bodies (unbounded arrays, base64 inflation, oversized multipart attachments).
- 4Retest with controlled payload sizes near the threshold to validate boundary behavior.
Payload Size Boundary Analysis
- -Measure serialized byte size after encoding (example: base64 attachment increases payload by ~33% and crosses 10 MB limit).
- -Inspect request composition for unbounded fields (example: client sends full history array instead of incremental delta).
Edge-to-Origin Limit Alignment
- -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 strategy compatibility (example: switch large media from JSON POST to resumable multipart upload endpoint).
Implementation Examples
curl -i -X POST https://api.example.com/v1/resource -H "Content-Type: application/json" -d "{"sample":true}"
# Response:
# HTTP/1.1 413 Content Too Large
# {"error":"Content Too Large","code":"413"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Accept': 'application/json' },
body: JSON.stringify({ sample: true })
});
if (response.status === 413) {
console.error('Handle 413 Content Too Large');
}import requests
response = requests.post(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json', 'Content-Type': 'application/json'},
json={'sample': True}
)
if response.status_code == 413:
print('Handle 413 Content Too Large')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 or proxy-side drops.
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.
Pro Tip
- -store rolling p95/p99 request-body size by endpoint and alert before values approach hard limits, not after 413 spikes start.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.