HTTP 413 payload too large error

What 413 means

HTTP 413 Payload Too Large says the request body (the part after the headers: the uploaded file, the form POST, or the JSON payload) is bigger than the server allows. It is useful because it is precise: the server did not choke on the URL or the method, it rejected the body on size. The text varies ("Payload Too Large", "Request Entity Too Large", "File too large"), and the client's message reflects whichever proxy spoke it.

Who sends the 413

The layer that answers first also names the limit to raise:

The media upload article covers the WordPress/PHP size pair; this article is the nginx/Apache/proxy layer that sits in front of PHP.

The four sizes, one chain

A request body passes a chain, and each link has its own limit. A 413 can come from any of them:

1. The web server. Nginx: client_max_body_size 25m; in a server or location block. Default is 1 MB, so a large file upload fails until it is raised.
2. The proxy or cloud load balancer. Many CDNs and LBs reject bodies over 25 MB or 100 MB before nginx or Apache sees them, and reply with their own 413.
3. Apache. LimitRequestBody (bytes, default 1 GiB on Linux, often a much lower panel-configured value). cPanel/WHM panels frequently set a 1 MB or 2 MB PHP bound in the handler that mirrors the same failure.
4. PHP (when the body reaches it): upload_max_filesize and post_max_size, as in the media upload article.

Raise the one the error line names, not all four.

Read the error that names the layer

The same page request yields a different trace per layer:

curl -i -X POST https://example.com/api/upload --data-binary @big.bin
HTTP/1.1 413 Payload Too Large

Then look in the log beside it:

• Nginx: client intended to send too large body in nginx/error.log
• Apache: Request entity is too large in the Apache access or error log
• Proxy: the edge vendor's error view, e.g. a CDN "413" with its own body

The error log reading article explains mapping a line to the layer that logged it.

The fix order

1. Confirm the true size. ls -lh the file, and check the form/API sends what you think: a mobile library that re-encodes can double the body.
2. Raise the named limit, in the named file. Nginx:

location /uploads {
    client_max_body_size 30m;
}

Then nginx -s reload (the setting is read on reload; no restart needed).

1. Check the proxy ahead of the origin. If the site is behind a CDN or cloud LB, its own limit (typically lower than the origin's) returns the 413 before your server even sees the request. Raise it there, or pre-size objects so uploads go to a URL that bypasses the body limit (S3 presigned uploads, or a dedicated upload host).
2. Look for a cascade. A root cause one layer down: nginx serves fine over proxy_pass but the LB in front caps at 10 MB. A 413 from the first hop hides a healthy origin.
3. If the upload is genuine production traffic (tens of MB files), the honest fix is out-of-band: upload to object storage with a presigned URL and reference it, keeping the web server body limit at a sane guardrail. The performance CDN article covers why that also wins on load.

Prevention

• Set client_max_body_size deliberately (default 1 MB is the silent cause of most "file too large" reports).
• Keep upload limits in four places aligned: web server, proxy, PHP, and the app's own validator.
• Check front-end validators mirror the server: an app that allows 50 MB while nginx allows 1 MB fails loudly for nobody.
• After a host migration, compare the old nginx.conf/.htaccess limits with the new ones before announcing the move.

When a large body also returns a bad request or times out instead of 413, the cause is the request itself or a proxy that reads it too slowly; the 400 bad request and 504 gateway timeouts references are the adjacent articles.