,{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Why does nginx return 413 instead of my application?","acceptedAnswer":{"@type":"Answer","text":"nginx reads the request body before passing to upstream. If the body exceeds client_max_body_size, nginx returns 413 immediately. Configure nginx limits to match or exceed your application limits."}},{"@type":"Question","name":"How does Expect 100-continue help with 413?","acceptedAnswer":{"@type":"Answer","text":"A client sends headers first. The server checks Content-Length and returns 413 before the client sends the body, saving bandwidth. Without it, the full body uploads only to be rejected."}}]}

HTTP 413 Content Too Large

Quick reference

Code413
NameContent Too Large (was "Payload Too Large")
Category4xx Client Error
SpecRFC 9110 §15.5.14
Retryable?Only with a smaller body

What 413 means

HTTP 413 Content Too Large (renamed from "Payload Too Large" in RFC 9110) means the server refuses to process the request because the request body is larger than the server's configured maximum. The server may close the connection after sending 413, or it may leave the connection open and discard the remaining body.

RFC 9110 notes that if the condition is temporary (for example, a server under load temporarily reducing its maximum), the response may include a Retry-After header indicating when to retry. For permanent size limits, no retry header is expected.

413 is a server-level rejection that fires before the body is fully processed. The server reads enough to determine the body is too large — either from a Content-Length header that exceeds the limit, or from reading the body itself until the limit is reached — then stops and responds with 413.

Common causes

File upload exceeding server limit. A user tries to upload a 50 MB image to a server configured with a 10 MB maximum. The most common scenario, and the most frequently misconfigured server-side setting.

JSON API body too large. A bulk import endpoint receives a JSON array with thousands of items. The raw JSON body exceeds the framework's body parser limit (commonly 100 KB by default in Express.js).

Base64-encoded file in JSON body. An API sends image or file data as a base64-encoded string within a JSON payload. Base64 adds ~33% overhead, so a 7.5 MB image becomes a ~10 MB JSON string — exceeding most default limits.

Multipart form with multiple large files. A form with multiple file inputs submits all files in a single multipart request. Each file is within the per-file limit but the combined multipart body exceeds the total request size limit.

Server configuration fixes

nginx — the most common source of 413, since nginx's default is 1 MB:

server { # Increase upload limit to 50 MB for this server: client_max_body_size 50M; # Or for a specific location only: location /api/upload { client_max_body_size 100M; } # Disable the limit entirely (not recommended for public endpoints): client_max_body_size 0; } # After changing: reload nginx (no downtime): nginx -t && systemctl reload nginx

Apache — set LimitRequestBody:

# httpd.conf or .htaccess: LimitRequestBody 52428800 # 52428800 bytes = 50 MB # 0 = no limit (use with caution)

Express.js — express default body limit is 100 KB:

const express = require('express'); const app = express(); // JSON body limit: app.use(express.json({ limit: '50mb' })); // URL-encoded form body limit: app.use(express.urlencoded({ limit: '50mb', extended: true })); // Multipart (using multer): const multer = require('multer'); const upload = multer({ limits: { fileSize: 50 * 1024 * 1024, // 50 MB per file files: 5, // max 5 files per request fieldSize: 2 * 1024 * 1024 // 2 MB per field } });

Django — set FILE_UPLOAD_MAX_MEMORY_SIZE and DATA_UPLOAD_MAX_MEMORY_SIZE in settings.py:

FILE_UPLOAD_MAX_MEMORY_SIZE = 52428800 # 50 MB DATA_UPLOAD_MAX_MEMORY_SIZE = 52428800 # 50 MB total form data

Client-side patterns to avoid 413

Chunked / multipart upload for large files: Instead of sending the entire file in one request, use chunked uploads. The client splits the file into chunks (e.g., 5 MB each) and uploads them sequentially or in parallel. The server reassembles the chunks. Protocols like tus provide a standardized implementation.

Presigned URLs for object storage: Rather than uploading files through the application server, generate a presigned S3, GCS, or Azure Blob URL and have the client upload directly to the object store. The application server never touches the file, eliminating server-side size limits:

# Backend: generate presigned URL (Python boto3) import boto3 s3 = boto3.client('s3') url = s3.generate_presigned_post( 'my-bucket', 'uploads/' + filename, ExpiresIn=3600, Conditions=[['content-length-range', 0, 100 * 1024 * 1024]] ) return url # client uses this to upload directly to S3

Compress before upload: For compressible content (text, JSON, CSV), compress client-side before uploading. A 20 MB CSV may compress to 3 MB, well within server limits.

413 vs related codes

CodeWhat was too large
413Request body
414Request URI / URL
431Request headers
507Server storage (not the request size)

Frequently asked questions

Why does nginx return 413 instead of my application?

nginx reads the request body before passing it to the upstream application. If the body exceeds client_max_body_size, nginx returns 413 immediately without proxying to the backend. This is efficient (saves backend resources) but means your application-level 413 handling code never runs. Configure nginx to match or exceed your application's limits.

Does 413 close the connection?

It may. RFC 9110 says the server may close the connection after 413 if it cannot discard the remaining body efficiently. nginx closes the connection on 413 by default. Clients should handle 413 responses and not assume the connection is reusable for retry.

How does Expect: 100-continue help with 413?

A client can send request headers first with Expect: 100-continue. The server can check the Content-Length header and return 413 before the client sends the body, saving bandwidth. Without 100-continue, the client uploads the full body only to have the server reject it. Most HTTP clients support this optimization; enable it for large upload clients.

What is the difference between 413 and 507?

413 Content Too Large means the request body exceeds the server's configured maximum body size — a configuration limit. 507 Insufficient Storage means the server has enough configured capacity to accept the request but physically does not have the disk/database space to store the content — a resource exhaustion condition.

Related guides

HTTP 414 · HTTP 431 · HTTP 507 · HTTP 411 · HTTP 100

Client Errors Hub · All Guides · Home