Is 413 Content Too Large the same as 413 Payload Too Large?

Yes. It is the same code. Older specifications called it Request Entity Too Large and later Payload Too Large; RFC 9110 renamed it Content Too Large. Many servers still print one of the older names.

I raised client_max_body_size but still get 413. Why?

Another layer has its own limit. Check the CDN or load balancer in front, any other nginx server or location block that overrides the setting, and the application's body parser or upload middleware.

Does 413 mean my file is corrupted?

No. The server rejected the request based on size alone, usually before reading the whole body. The file itself is fine.

413 Content Too Large — HTTP Status Code

What 413 means

RFC 9110 (Section 15.5.14) defines 413 Content Too Large as the server refusing to process a request because the request content is larger than it is willing or able to handle. The server may end the request early or close the connection. If the limit is temporary, the server should send a Retry-After header saying when to try again.

The name has changed over the years, which causes confusion in search results and error messages. Older documents call it "Request Entity Too Large" or "Payload Too Large." The code and meaning are the same.

When you see it

Every layer that receives a request body can enforce a limit, so a 413 can come from several places:

nginx, via client_max_body_size, which defaults to 1 MB. This is the most common source on self-hosted sites.
Apache, via LimitRequestBody.
CDNs and proxies. Cloudflare, for example, limits upload size per request depending on the plan; check your provider's documentation for the current figure.
API gateways and serverless platforms, which cap request size for function invocations.
Application frameworks. Express's express.json() rejects bodies above its limit option (100 KB by default) with 413, and upload libraries such as multer have their own file size limits.

Common causes

Uploads of images, videos or backups that exceed the default nginx limit.
Large JSON payloads, such as bulk imports or base64-encoded files sent inside JSON, which grow by about a third compared with the raw binary.
Limits set in one place but not another, for example nginx raised but the app's body parser left at its default.
A setting in the wrong block. An nginx location block with its own client_max_body_size overrides the value from the server block.

How to fix it

Work through the request path from the outside in and raise each limit to the size you actually need, not to "unlimited."

In nginx, set the limit where uploads happen:

server {
    client_max_body_size 10m;          # site-wide default

    location /api/upload {
        client_max_body_size 200m;     # larger only where needed
        proxy_pass http://app;
    }
}

Reload with nginx -t && systemctl reload nginx. In Apache, LimitRequestBody takes a value in bytes:

<Location "/api/upload">
    LimitRequestBody 209715200
</Location>

In the application, match the proxy's limit:

app.use(express.json({ limit: "5mb" }));

For PHP sites, also check upload_max_filesize and post_max_size in php.ini. PHP does not send a 413 itself when they are exceeded; it discards the upload, so the app sees an empty request instead.

For very large files, the better fix is often architectural: upload directly to object storage with a pre-signed URL, or split the file into chunks with a resumable upload protocol. That keeps huge bodies away from your web servers entirely.

How to check it

Generate a test file of a known size and post it, printing just the status:

head -c 5000000 /dev/urandom > /tmp/5mb.bin
curl -sS -o /dev/null -w "%{http_code}\n" \
  -F "file=@/tmp/5mb.bin" https://example.com/api/upload

Repeat with smaller and larger files to find the threshold. Add -i and drop -o /dev/null to see which server produced the error page; nginx, Cloudflare and your app each format it differently.

What it means for uptime monitoring

PingRobot's checker sends a GET with no request body and the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and treats the final response as up only if its status is 200 to 399. A 413 would count as down, but since the check sends no body, a 413 in response to it would be very unusual and points to a badly misconfigured server rather than a size issue.

The more realistic risk is the opposite: uploads are failing for real users while your monitored home page stays green. Availability checks cannot see that. If uploads are critical, test them as part of your deploy process and watch your logs for 413 responses.

414 URI Too Long when the URL, not the body, is too big
431 Request Header Fields Too Large when headers are too big
408 Request Timeout, another common upload failure
415 Unsupported Media Type when the body format is rejected
400 Bad Request for other malformed requests

Start monitoring free — 10 monitors, no credit card.