413 Request Entity Too Large

The short version: The body you sent is bigger than the server will accept. Uploading something? Send a smaller file, or split it across several submissions. Running the server? On nginx, raise client_max_body_size from its 1m default, then raise the matching limit in your application runtime too, because PHP, ASP.NET and Node each enforce one of their own.

Key takeaways

• A 413 means the server refused the request because the body was larger than it is willing to read. It usually decides from the Content-Length header alone, before a byte of your file has arrived, which is why a huge upload can fail almost instantly.
• The name changed twice. RFC 2616 called it Request Entity Too Large, RFC 7231 renamed it Payload Too Large, and RFC 9110, the current HTTP specification, calls it Content Too Large. All three describe the same status, and servers still send the older phrases.
• On nginx this is nearly always client_max_body_size, which defaults to 1m. nginx rejects the request itself, so your application never runs and never logs it, and there is nothing to debug in the app.
• Two limits usually have to move together: the web server's and the application runtime's. Raise client_max_body_size but leave PHP's upload_max_filesize and post_max_size alone and the 413 disappears, replaced by an upload that silently does nothing.
• Every hop counts. A CDN, a WAF, a load balancer, and the origin each carry their own body ceiling, and the smallest one wins. Cloudflare caps uploads at 100 MB on Free and Pro no matter how generous your origin config is.

Error type

HTTP 4xx client error

Whose side

Usually the website config; sometimes what you sent

Fix difficulty

Easy to moderate

Common cause

Request body exceeds a configured size limit

What does 413 Request Entity Too Large mean?

A 413 is a client-error response saying the request body was larger than the server is willing or able to process. RFC 9110, the current HTTP specification, names it Content Too Large and adds that the server may terminate the request, or otherwise close the connection. It is a size decision and nothing more. Authentication, routing, permissions, whether the endpoint even exists: none of that gets evaluated, because the server ruled on the Content-Length header and stopped there. That is why a 413 on a 500 MB upload can come back in milliseconds, long before the file has finished going anywhere.

The confusing part is that the refusal happens above your application. A normal request passes through a CDN, then a load balancer or reverse proxy, then the web server, then the runtime holding your code, and every one of those enforces its own body ceiling. Whichever ceiling is smallest answers first, so your code never runs, never logs, and has nothing to show you. Fixing a 413 is therefore a hunt for the layer that owns the smallest number, followed by raising the limit in each layer that would have objected next. RFC 9110 also says a server should send a Retry-After header when the limit is temporary, though in practice most 413s come from a fixed configured value rather than a passing condition.

413

HTTP status code

1 MB

Default nginx request body limit

2M / 8M

PHP upload_max_filesize and post_max_size defaults

RFC 9110

Spec that renamed it Content Too Large

How the 413 Request Entity Too Large error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/upload

413

Request Entity Too Large

The requested resource does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.

• 413 Request Entity Too Large
• 413 Payload Too Large
• 413 Content Too Large
• Request Entity Too Large nginx
• 413 Request Entity Too Large nginx
• nginx 413
• HTTP Error 413
• 413 error
• HTTP Error 404.13 - CONTENT_LENGTH_TOO_LARGE

413 vs 400, 414 and 431

All four mean the server rejected the shape or the size of your request, but each one points at a different part of it.

Request body limits by layer, and their defaults

A 413 is one of these settings firing. Find the layer that owns the smallest number and you have found the fix.

Which layer sent the 413, and how to tell

The same status code comes from at least four different places in a normal stack, and each one leaves a different fingerprint.

What causes 413 Request Entity Too Large?

• An upload larger than the web server's body limit. On nginx that is client_max_body_size, and its default of 1m catches more people than any other single setting on this page.
• A POST or JSON body over the application framework's own parser limit, which is often far smaller than the web server's. Express and its body parser, for instance, ship a 100 KB default for JSON.
• PHP left at its defaults, upload_max_filesize at 2M and post_max_size at 8M, while the web server in front of it was raised.
• Base64 encoding a file into a JSON body, which adds roughly a third to its size, so a file comfortably under the limit arrives over it.
• Several files submitted through one multipart form, where the limit applies to the whole request body rather than to each file separately.
• A CDN or WAF ceiling sitting in front of the origin. Cloudflare allows 100 MB uploads on its Free and Pro plans regardless of what your own server would have accepted.
• A reverse-proxy chain where only one hop was raised, so the request clears the edge and then dies at the next box along.
• Windows stack defaults: IIS request filtering at maxAllowedContentLength of roughly 28.6 MB, or ASP.NET's maxRequestLength at 4 MB.
• A deliberate API limit, sometimes documented and sometimes not, meant to stop one client posting an enormous payload.

How to find the cause fast

1. Confirm the code and find out who sent it. Repeat the request with curl -sS -D - -o /dev/null and read both the status line and the Server header on the 413.
2. Measure the real body size, not the file size on disk. The browser network panel reports the payload it sent, and curl -v prints the Content-Length on the request line. That number is the one the server judges.
3. Read the web server error log. nginx writes client intended to send too large body along with the byte count it saw, which usually settles the question in a single line.
4. Bypass the edge. Send the same request straight to the origin IP, or to a DNS-only hostname; if it succeeds there, the CDN or WAF owns the limit.
5. Check the application runtime last. If the 413 stops but the upload still fails silently, the web server let the body through and the runtime is now the one rejecting it.

Terminal

curl -sS -D - -o /dev/null -F 'file=@report.pdf' https://example.com/uploadHTTP/1.1 413 Request Entity Too LargeServer: nginxConnection: close# nginx refused the body before reading it: raise client_max_body_size

How 413 Request Entity Too Large looks from the outside

A 413 is nearly invisible to ordinary monitoring, because triggering it takes a large request body and monitoring checks are small GETs. The homepage stays green, the API health check stays green, and meanwhile every upload on the website fails. The way a 413 arrives makes it worse: the server answers immediately and correctly, so there is no slow response, no timeout, no connection error, nothing that resembles trouble from the outside. The changes that cause one are quiet too. A deploy that overwrites an nginx config, a container image built without your tuned php.ini, or a plan change at the CDN can each reset a limit to its default without anyone touching the upload code. Checking the specific endpoints that matter, and asserting the status code you expect on each, is what turns this into an alert rather than a run of support tickets.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 413 Request Entity Too Large

If you are uploading a file

1. Shrink the file. Compress an image, export the PDF at a lower resolution, or zip a set of documents before sending them.
2. Split the upload. Several smaller submissions usually get through where one large one does not, because the limit applies per request.
3. Send fewer files per submission. The limit covers the entire request body, so four files attached to one form add together.
4. Look for a stated maximum on the page or in the API documentation and stay under it rather than guessing at the ceiling.
5. Calling an API? Send the file as a normal multipart upload instead of base64 inside a JSON body, which avoids adding a third to its size.
6. If the file is genuinely inside the stated limit, the ceiling is misconfigured. Tell the website owner, and include the file size and the exact time you tried.

If you run the website: the web server and the edge

1. On nginx, raise client_max_body_size from its 1m default. Scope it to the location that handles uploads where you can, run nginx -t, then reload.
2. On Apache, find the LimitRequestBody that someone set. It defaults to 0, meaning unlimited, so a 413 from Apache means it was configured somewhere: a vhost, a Directory block, or an .htaccess file in the upload path.
3. On IIS, raise maxAllowedContentLength inside requestFiltering, in bytes, and remember the request filtering block can live in applicationHost.config as well as in your web.config.
4. Raise the limit at every hop the request passes through. A load balancer, a reverse proxy, and the origin each enforce their own, and the smallest one decides.
5. Check the CDN or WAF ceiling. On Cloudflare that is the maximum upload size for your plan, and a zone administrator can lower it from the Network settings.
6. Keep the new limit deliberate rather than unlimited. client_max_body_size 0 does switch the check off, and it also hands anyone on the internet a way to fill your disk.

If you run the website: the application runtime

1. For PHP, raise upload_max_filesize and post_max_size together, keeping post_max_size the larger value because the body carries the file plus every other form field.
2. Keep memory_limit above post_max_size, as the PHP manual recommends, so a large upload does not fail on memory instead.
3. Restart PHP-FPM after editing, then confirm with phpinfo() or php -i that the values you changed are the ones in effect. A per-pool or per-vhost override quietly beats the global php.ini.
4. On ASP.NET, set maxRequestLength in httpRuntime, measured in kilobytes, alongside the byte value in maxAllowedContentLength. On ASP.NET Core, set the Kestrel MaxRequestBodySize, or override it for the single endpoint that needs it.
5. On Node, Express and similar frameworks, raise the body parser limit only on the routes that accept uploads rather than across the whole app.
6. For anything past roughly 100 MB, move to chunked or resumable uploads, or hand the browser a presigned URL so the file goes straight to object storage and never touches your web server.

Still not fixed? Next steps

• Reproduce it with curl and read the Server header on the 413 itself. That names the box in the chain that refused you, and it is often not the one you have been editing.
• Measure what actually goes on the wire. Multipart forms wrap every field in boundary markers, several files in one submission add together, and base64 encoding inflates a payload by roughly a third, so a 45 MB file can arrive as a 60 MB body and trip a 50 MB limit.
• Walk the chain from the edge inward: CDN or WAF, then the load balancer, then the web server, then the application runtime. Raise the limit at every hop, because the smallest number in the chain is the one that decides.
• If uploads regularly run to tens or hundreds of megabytes, stop raising ceilings and change the shape of the upload. Chunked or resumable uploads, or a presigned URL that sends the file straight to object storage, keep the large body away from your web server entirely.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

nginx: raise client_max_body_size where the uploads land

# The default is 1m, and it applies to http, server and location blocks.
# The innermost matching value wins, so scope it as tightly as you can.
http {
  client_max_body_size 1m;            # site-wide default stays small

  server {
    server_name example.com;

    location /upload/ {
      client_max_body_size 64m;       # this path only
      proxy_pass http://app_backend;
    }
  }
}

# client_max_body_size 0; disables the check entirely. Avoid that on
# anything public: it lets a stranger send a body of any size.
#
# Apply with:  nginx -t && nginx -s reload

PHP: both values must move, and post_max_size must be the larger one

; php.ini defaults are upload_max_filesize = 2M and post_max_size = 8M.
; post_max_size covers the WHOLE body: the file plus every other form
; field plus multipart boundaries, so leave it comfortably above
; upload_max_filesize or large uploads still fail.

upload_max_filesize = 64M
post_max_size       = 72M
memory_limit        = 256M    ; the PHP manual: keep this above post_max_size
max_file_uploads    = 20

; If post_max_size is exceeded, PHP does NOT send a 413:
; $_POST and $_FILES simply arrive empty. That silent failure is the
; usual sign the web server limit was raised and this one was not.

; Verify what is actually loaded, then restart the pool:
;   php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit'
;   systemctl restart php-fpm

Reproduce a 413 with curl and a large body

# Build a 5 MB test file (portable across macOS and Linux)
dd if=/dev/zero of=/tmp/big.bin bs=1024 count=5120

# POST it and print the status code only
curl -sS -o /dev/null -w '%{http_code}\n' \
  -F 'file=@/tmp/big.bin' https://example.com/upload
# 413

# Same request with the response headers, to see WHICH server refused it
curl -sS -D - -o /dev/null -F 'file=@/tmp/big.bin' https://example.com/upload
#   HTTP/1.1 413 Request Entity Too Large
#   Server: nginx
#   Connection: close

# nginx compares Content-Length against the limit before reading the body,
# so the 413 comes back almost immediately. Over HTTP/1.1 curl also adds an
# Expect: 100-continue header for a body this size, which lets the server
# refuse it without the 5 MB ever leaving your machine.

IIS and ASP.NET: two limits, two different units

<configuration>
  <system.web>
    <!-- ASP.NET on .NET Framework. KILOBYTES. Default 4096 (4 MB). -->
    <httpRuntime maxRequestLength="102400" />
  </system.web>

  <system.webServer>
    <security>
      <requestFiltering>
        <!-- IIS request filtering. BYTES. Default 30000000 (about 28.6 MB). -->
        <requestLimits maxAllowedContentLength="104857600" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

<!-- 102400 KB and 104857600 bytes are both 100 MB. Raise only one of them
     and the lower ceiling still decides. When request filtering blocks the
     body, IIS shows HTTP Error 404.13 CONTENT_LENGTH_TOO_LARGE and logs the
     413.1 substatus, so the visible error says Not Found. -->

How to prevent 413 Request Entity Too Large

A 413 rarely shows up on the homepage, and that is what makes it easy to miss: the website looks perfectly healthy while every upload quietly fails after a deploy overwrites a config or a container ships without your tuned limits. Pulsetic checks the URLs you choose from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord or webhook when one stops returning the status you expect. It measures availability from outside your infrastructure, so it can tell you an endpoint is answering 413; it cannot read your nginx config or your PHP settings for you.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.