413 Request Entity Too Large: causes and fixes

What 413 Payload Too Large means

RFC 9110 defines the current name as 413 Content Too Large, though 413 Payload Too Large and the older 413 Request Entity Too Large both refer to the same status code and still appear across servers, frameworks, and error pages. Whatever the wording, the meaning is identical: the request itself was syntactically fine, but its body exceeded a size limit before the server would accept it for processing. This most often happens on file uploads, but it can happen on any request with a large body, including a bulk API payload.

How the error appears

Browsers usually show whatever plain error page the origin server or edge sent back; there is no dedicated browser UI for this the way there is for a connection failure. It is common to see it fail silently in a form, with the response only visible in the network tab, especially for a file upload built with JavaScript. From the command line, the response confirms it directly:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Server access and error logs are the most reliable place to confirm the exact size involved and which layer rejected it, since a request can be blocked at the CDN, the web server, or the application, and each one logs it differently.

What causes a 413

• nginx's client_max_body_size. The default is 1 MB, which is small enough that almost any real file upload trips it until it is explicitly raised:

  client_max_body_size 20M;

• Apache's LimitRequestBody. Set per directory or globally, and, like nginx, defaults to a size many applications exceed without anyone changing it on purpose.
• PHP's upload_max_filesize and post_max_size. Two separate settings in php.ini that both need to be large enough for the upload; post_max_size must be at least as large as upload_max_filesize or the second setting caps the first silently.
• IIS's maxAllowedContentLength. Set in web.config under requestLimits, defaulting to about 30 MB, and separate from ASP.NET's own maxRequestLength setting, which uses different units and needs to be raised alongside it.
• Cloudflare's plan-based upload limit. Free and Pro plans cap request body size at 100 MB regardless of what the origin server would otherwise accept, and this limit cannot be raised from the origin's own configuration; it has to be addressed on the Cloudflare side or worked around with a direct upload path that bypasses the proxy.
• API gateway payload limits. Managed API gateways commonly cap request bodies well below what a traditional web server would allow, often in the low single-digit megabytes, which catches teams migrating an existing upload feature behind a new gateway.

How to tell whose fault it is

This is almost never a visitor's fault in the sense of doing something wrong; the file they are uploading is simply larger than a limit that exists somewhere in the chain, and the fix belongs to whoever owns that layer. If the same file uploads fine on one environment and fails on another, compare every layer in the request path, since nginx, PHP, and a CDN can each have a different limit and the smallest one wins. Running an HTTP check with a request body near your intended limit, sent from outside your network, confirms what the effective ceiling actually is end to end rather than relying on any single config file.

How to fix a 413 error

If you are a visitor

1. Compress the file before uploading, especially images and videos, which often shrink dramatically with no visible quality loss at typical sizes.
2. Split a large upload into smaller pieces if the site supports chunked or resumable uploads, rather than sending one very large request.
3. Check the site's stated upload limit if one is published, since some 413s are working as intended and the fix is simply a smaller file.

If you run the site

1. Raise every layer's limit together, not just one. A single request typically passes through a CDN, a web server, and an application runtime, and the smallest configured limit anywhere in that chain determines the actual ceiling.
2. Set nginx and Apache explicitly rather than relying on defaults:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Match PHP's two settings. Raise both upload_max_filesize and post_max_size, and make sure the second is equal to or larger than the first.
4. Update IIS's requestLimits and ASP.NET's maxRequestLength together in web.config, since they measure the same thing in different units and both need raising.
5. Work around Cloudflare's plan limit for genuinely large files by uploading directly to storage with a signed URL, bypassing the proxied request path entirely, rather than trying to raise a limit that plan tier does not expose.
6. Check the API gateway's own payload limit separately from the backend service if one sits in front of your application; it can reject a request before your own, more generous, application settings ever get a chance to apply.

How to prevent a 413 blocking real users

A limit set too low is easy to miss until someone with a large file hits it, and by then it looks like a broken upload feature rather than a configuration mismatch. A scheduled HTTP check that submits a request near your intended size limit, with an assertion on the expected status code, confirms the whole chain still accepts it after any change to the CDN, web server, or application config. Combined with monitoring from multiple locations, it also catches a CDN-level limit that only applies at certain edge nodes.

Related errors

See 400 Bad Request, which some servers return instead of 413 for the same oversized-body condition, the 4xx overview for the wider family, and 406 Not Acceptable elsewhere in this batch.

Frequently asked questions

Is 413 Payload Too Large the same as 413 Request Entity Too Large?

Yes. RFC 9110 renamed the status text to 413 Content Too Large, but both older names refer to the identical status code and meaning, and all three phrasings still appear in the wild depending on the server software's version.

Why does my upload fail even though I raised nginx's client_max_body_size?

Another layer in the chain, commonly PHP's post_max_size, a CDN's fixed plan limit, or an API gateway, is likely enforcing a smaller limit independently. Every layer between the client and the application needs to allow the size, not just the one you changed.

Can I raise Cloudflare's 100 MB limit on the free or pro plan?

Not from the origin server's own configuration; that ceiling is fixed by the plan tier. The usual workaround is uploading large files directly to storage using a signed URL that bypasses the proxied request path.

Does 413 count as a security block?

Not typically. It is usually a straightforward resource limit rather than a defensive rule, though some WAFs do use unusually large bodies as one signal among several when deciding whether to block a request.

What is a reasonable default upload limit if I have not set one?

There is no universal number; it depends entirely on what your application legitimately needs to accept. Set it deliberately based on your largest expected legitimate file rather than leaving each layer's default in place.