413 Error | Fix Upload Limits Fast

A 413 error means the server rejected your request because the upload or payload is larger than the allowed limit.

You’ll usually see status 413 when you upload a file, paste a big chunk of text into a form, or send a large API request. It can feel random because the limit might live in a few different places: a CDN, a reverse proxy, your web server, your app, or the language runtime behind it.

This guide helps you find the exact choke point, raise the limit safely, and confirm the fix without guessing. You’ll get quick checks first, then server-specific steps for the most common stacks.

What A 413 Error Means On The Wire

HTTP status code 413 is a client error response that tells you the request body was too large for what the server is willing to accept. The key detail is “request body.” Your URL can be short, your headers can be fine, and you can still hit the limit if the body is big.

Many platforms used to label it “Request Entity Too Large.” Newer references often call it “Content Too Large.” Both point to the same idea: the server set a cap, and your request crossed it.

Common Ways It Shows Up

Upload a media file — Images, PDFs, zip files, and videos are the classic trigger.
Send a big API payload — JSON with long arrays, base64 blobs, or multi-part forms can trip a gateway limit.
Submit a large form — Long text areas and many fields can push the body past a configured cap.
Push a large build artifact — Some endpoints treat artifact uploads like any other request body.

Why It Feels Inconsistent

Status 413 can come from the first layer that checks size. If you sit behind a CDN, the CDN may reject it before your origin sees it. If you run a reverse proxy, the proxy may block it before your app code runs. If the proxy allows it, your app or runtime can still refuse it later.

Quick Checks That Pinpoint The Limit

Start with two simple facts: the actual size of the request body and the layer that returned the response. Once you know those, the fix turns from guesswork into a short edit-and-reload.

Find The Failing Layer

Check the response headers — Look for server identifiers like nginx, Apache, IIS, or a CDN edge header.
Watch the status in dev tools — In the Network panel, open the failed request and note the response headers and timing.
Try the same request on origin — If you can bypass the CDN with a direct origin URL, you can see whether the edge is the blocker.

Use A Simple Size Table

The table below helps you map the symptom to the most likely limit. Treat it as a starting point, then confirm in logs.

Where You See It	Typical Cap	What To Check First
CDN or proxy returns 413 instantly	Plan-based upload size	Edge upload limit settings
nginx returns 413 before app logs show a hit	client_max_body_size	nginx site or location block
App logs show the route ran, then fails	Runtime or app cap	PHP, framework, or middleware limits
Only some routes fail	Per-route rule	Location, route, or gateway overrides

Check Logs Before You Change Anything

Read the web server error log — It often spells out the limit and the directive name.
Scan proxy and gateway logs — They may log “body too large” even when the browser only shows status 413.
Confirm the payload size — Use your client to print Content-Length, or measure the file on disk.

If you control the client, send a tiny test request first. Then step up in size until it fails. That failure point is your real ceiling, often.

Fixing Upload Limits On Nginx

If your response header shows nginx and the request never reaches your app, the most common fix is raising client_max_body_size. It sets the maximum allowed size of the client request body. When the request exceeds that value, nginx returns status 413.

Pick a limit that matches your real use. If users upload 20 MB photos, set the cap a bit higher than that, not “unlimited.” A tighter cap helps reduce abuse and accidental over-uploads.

Set The Limit In The Right Place

Edit the site config — Place the directive in the server block for the domain that serves the upload.
Use a location override — If only one path needs large uploads, set it only in that location block.
Reload nginx — After changes, reload the service so the new value takes effect.

Common Gotchas With Nginx Uploads

Match upstream limits — If nginx allows 50 MB but PHP allows 2 MB, uploads still fail, just later.
Check multiple config files — A higher value in one file can be overridden by a lower value in another context.
Watch for edge caps — If a CDN sits in front, nginx may never see the request body that is being blocked.

Fixing Upload Limits On Apache And PHP

On Apache, a size limit can be enforced at the server layer and at the PHP layer. If you raise one and forget the other, you’ll still see failures, just with a different message or status.

Apache Limits To Review

Adjust LimitRequestBody — This directive sets a maximum request body size in the context where you define it.
Check header size directives — If your request has huge cookies or headers, you might hit header limits instead of body limits.
Confirm where overrides apply — A per-directory rule can behave differently than a vhost rule.

PHP Upload Limits That Often Cause Failures

Raise upload_max_filesize — This controls the maximum size of an uploaded file that PHP will accept.
Raise post_max_size — This caps the total size of the POST body, including file and form fields.
Check memory_limit — Large uploads can still fail if your script needs more memory to process them.

WordPress-Specific Notes

In WordPress, media uploads can hit your hosting stack limits long before WordPress itself complains. If you use a managed host, there may be a control panel setting for upload limits that maps to the same server directives.

Test with a known file — Upload one file that is just under the target size, then one that is just over it.
Check the REST API too — Some plugins send large JSON payloads and can trip the same response.
Keep the limit consistent — Align CDN, web server, and PHP caps so uploads behave predictably.

Fixing Upload Limits On IIS And .NET

On IIS, request size limits are often controlled by request filtering and framework settings. You may see variants like “413.1” with more detail. The fix is still the same idea: raise the cap where it is enforced.

IIS Settings That Commonly Block Large Requests

Set maxAllowedContentLength — This request filtering value controls the maximum allowed size of the request body.
Adjust uploadReadAheadSize — This controls how much data IIS buffers before passing the request along.
Check framework limits — ASP.NET and other components can enforce their own max request sizes.

Safer Testing On IIS

Increase in small steps — Move from 30 MB to 50 MB, then higher only if you need it.
Restart the right service — Config changes may require an app pool recycle or service restart.
Confirm on HTTPS — Buffering behavior can differ between setups.

Preventing Repeat Upload Rejections And Keeping Uploads Safe

Once you fix the immediate failure, spend a minute making sure the new limit won’t create a new problem. Bigger uploads raise resource use, raise the chance of timeouts, and widen the surface for abuse. A few guardrails keep things steady.

Set A Clear User-Facing Limit

Show the max file size — Put the limit near the upload button so people don’t waste time.
Validate on the client — Block obviously too-large files before the request leaves the browser.
Validate on the server — Still enforce the cap server-side, since clients can be bypassed.

Reduce Payload Size Without Breaking Quality

Compress images — Resize to the display width and export with sane settings.
Use chunked uploads — For large files, split into parts if your stack allows it.
Avoid base64 in JSON — Send binary as multipart or direct object storage uploads when you can.

Match Timeouts And Storage With The New Cap

Raising the byte limit is only one piece. If an upload takes two minutes on mobile data, your timeouts need to allow that. If you write uploads to disk, the target volume needs room, and your temp directory must not fill up mid-upload.

Review proxy timeouts — Set values that fit your slowest expected connection.
Check temp file paths — Ensure the server has disk space for buffering and post-processing.
Keep an eye on error spikes — A sudden jump in rejected bodies can hint at misuse or a broken client.

Confirm The Fix From Browser To Server

Don’t stop after a single successful upload. Run a quick set of checks so you know where the real ceiling is and whether you created a mismatch between layers.

Try three sizes — One small, one near the cap, and one slightly above it.
Watch the logs — Confirm you see normal app handling for accepted uploads.
Check CDN settings — If you use an edge network, align its max upload size with your origin.

When Status 413 Isn’t Really About Upload Size

Most of the time, status 413 points to body size. Still, there are edge cases where it’s a clue, not the full story. If your payload is small and you still hit status 413, check these patterns.

Request Headers Are Huge

Large cookies or long auth headers can push requests into server limits that feel like “size.” Some stacks return different codes, yet gateways can still surface status 413. Clearing cookies, trimming headers, and checking header size directives can reveal the real issue.

Proxies Buffer Or Rewrite The Body

A gateway may buffer the request, repackage it, or enforce a lower cap on specific routes. If only one endpoint fails, look for per-route rules in your gateway or your application middleware.

Edge Network Upload Caps

If you use Cloudflare, an upload can be rejected at the edge when it exceeds the plan’s maximum upload size. In that case, raising origin limits won’t help until the edge cap is raised or the upload path changes.

If you came here because you saw a 413 error in a browser popup, your fastest win is to find the first layer returning the response, then raise the matching limit and keep the rest aligned. Once the caps agree, uploads feel boring again, which is exactly what you want.