HTTP 413 Content Too Large: causes and fixes

What 413 means

The request body is bigger than the server is willing to accept, so it refused it without processing. 413 is defined in RFC 9110 §15.5.14 as "Content Too Large"; older specs called it "Payload Too Large" (RFC 7231) and "Request Entity Too Large" (RFC 2616), names you'll still see in error pages. The server may close the connection, and should send Retry-After if the limit is only temporary.

HTTP/1.1 413 Request Entity Too Large
Server: nginx
Connection: close
Content-Type: text/html

Common causes

An upload over the web server's limit. nginx's client_max_body_size is 1 MB by default, which a single phone photo can exceed.
A proxy in front with a lower limit than the app: a Kubernetes ingress, a CDN or a load balancer.
A large JSON body for a framework parser with a small default, such as Express's 100 KB.
Base64-encoded files inside JSON, which are a third bigger than the file itself.

Every layer has its own limit; the smallest one wins, so check them all.

How to fix it on the server

nginx (in http, server or location; 0 disables the check):

server {
    client_max_body_size 50m;
}

Kubernetes ingress-nginx: the annotation nginx.ingress.kubernetes.io/proxy-body-size: "50m" on the Ingress (it also defaults to 1m).

Apache: LimitRequestBody in bytes, per server or directory. Since 2.4.54 the default is 1 GiB; before that it was unlimited.

<Location "/upload">
    LimitRequestBody 52428800
</Location>

PHP: raise upload_max_filesize (default 2M) and post_max_size (default 8M) in php.ini. PHP itself doesn't answer 413: an oversized POST arrives with $_POST and $_FILES empty, which looks like a form that sent nothing.

Express: app.use(express.json({ limit: '5mb' })); the parser's PayloadTooLargeError becomes a 413.

Cloudflare caps the request body by plan (100 MB on Free and Pro, 200 MB on Business, 500 MB by default on Enterprise) and answers 413 above that. Send bigger files directly to storage instead of through the proxy.

Raise limits only where uploads happen, not site-wide: a small limit elsewhere protects the server from memory and disk abuse.

How to fix it as a client

Compress or resize files before uploading.
Upload large files in chunks, or with a resumable protocol such as tus or S3 multipart uploads.
Upload straight to object storage with a presigned URL, so the file never passes through your app server.
Send files as multipart/form-data instead of base64 inside JSON.

413 and SEO

None. Crawlers fetch pages with GET requests that have no body, so they never trigger 413. It only affects uploads, forms and APIs.

431 Request Header Fields Too Large: the headers, not the body, are too big.
400 Bad Request: what some servers send instead for an oversized header.
408 Request Timeout: the body was too slow rather than too big.
415 Unsupported Media Type: the body's format, not its size, is the problem.

To test an endpoint with a body of a given size, send it from the HTTP Request Builder.