413 Error Code | Fix Large Uploads Fast

You hit Upload, Save, or Submit… and the page snaps back with “413.” It feels abrupt because it is. The server is saying, “That payload is too big for the rules I’m running.”

The good news is that a 413 is usually a settings mismatch, not a mystery bug. Once you find which layer is enforcing the cap, you can raise the limit, shrink the payload, or split it into smaller chunks.

What Status 413 Means In Plain Terms

HTTP has a family of 4xx status codes that point to request issues. A 413 sits in that set and maps to a request body the server won’t accept. You’ll often see it during file uploads, large form posts, big JSON requests, or when an app sends a bulky batch of data.

Different products label it in slightly different ways. You might see “Request Entity Too Large,” “Payload Too Large,” or a short “413.” The message varies, yet the trigger is the same: a size threshold got crossed somewhere between your browser and the app that should handle the request. A 413 error code flags caps.

That “somewhere” matters. Your request can pass the browser, then get blocked by a CDN, a load balancer, a reverse proxy, the web server, a PHP layer, or the app itself. Fixing the wrong layer leads to a loop where you change a setting, retry, and still get the same wall.

413 Error Code On File Uploads And Forms

Uploads are the classic trigger, though it also pops up with large forms and API calls. The pattern is simple: you send more bytes than the smallest limit along the route.

Here are the usual triggers, in the order that tends to match real-world setups.

• Large media files — Video, raw photos, large PDFs, and uncompressed audio can exceed defaults on many hosts.
• Bulky WordPress imports — Theme ZIPs, plugin ZIPs, full-site backups, and XML imports can trip PHP or server caps.
• Big form submissions — Multi-select fields, long text fields, or forms that attach files can push a POST request over the cap.
• API payload spikes — A single JSON request that includes images, base64 blobs, or huge arrays can breach limits fast.
• Proxy or CDN ceilings — A reverse proxy or edge service can reject the request before your origin server sees it.

If you only control the application and not the server, shrinking the payload is often the fastest path. If you manage the stack, raising limits is fine too, as long as you also handle timeouts and abuse risk.

Fast Checks Before You Change Server Settings

Before editing config files, confirm what’s actually being sent. A 413 can come from a file that is larger than you think, or from a request that silently grew over time.

1. Check the file size — Compare the upload size to the limit you expect. Watch for MB vs MiB differences when a host shows one unit and your OS shows another.
2. Try a smaller test file — Upload a file that is well under 1 MB. If that works, you’ve confirmed the issue is size, not authentication or file type.
3. Retry with a different network — Some corporate proxies and security gateways enforce their own caps. A phone hotspot can be a quick sanity check.
4. Check the exact endpoint — An admin upload route might allow more than a public form route. Confirm you’re using the path your app expects.
5. Read the response headers — In DevTools, the Network tab often shows a server name or edge provider that hints at the layer throwing the 413.

If the headers show a CDN or reverse proxy, fix that first. If the response clearly comes from your origin, move to the server or app layer next.

Fixes For Common Setups

Most 413 fixes come down to raising a request body limit in one place and restarting the service, then matching related limits in the layers beneath it. Start with the layer closest to the user, then work inward.

Common Limits By Stack

Where The Limit Lives	Typical Setting Name	What To Do
CDN or reverse proxy	Request body size cap	Raise the cap or bypass uploads to origin for large files.
Nginx	client_max_body_size	Increase it in the right server block, then reload Nginx.
Apache	LimitRequestBody	Set a higher limit for the vhost or directory that handles uploads.
PHP	upload_max_filesize, post_max_size	Raise both, then restart PHP-FPM or the web server.
App layer	Body parser limit	Increase the limit in the app config and validate input handling.

Nginx Reverse Proxy Or Direct Nginx

If Nginx is in the chain, it’s a common source of a 413. The setting is client_max_body_size. It can be set at http, server, or location scope, and the smallest matching scope wins.

• Set a clear limit — Add client_max_body_size with a value that matches your use, such as 50m or 200m.
• Place it correctly — Put it in the server block that handles the domain, or the location block for the upload route.
• Reload safely — Validate config, then reload Nginx so you don’t drop connections.

If uploads still fail, check for a second proxy layer. Many stacks have Nginx at the edge and another proxy inside a container or platform.

Apache With PHP Or A Proxy Module

Apache can enforce a body cap with LimitRequestBody. It can be set per directory, per vhost, or in .htaccess if AllowOverride permits it.

• Find where uploads land — Match the directive to the directory or vhost that receives the POST.
• Set a numeric byte value — The directive uses bytes, so convert MB to bytes to avoid a tiny accidental cap.
• Restart the service — Apache needs a restart or graceful reload to apply changes.

If your app uses a proxy module, also check any proxy request limits in that path.

WordPress And PHP Limits

On WordPress, a 413 often shows up during theme uploads, plugin installs, media uploads, or restore jobs. The web server might allow the request, yet PHP can still reject it based on its own caps.

1. Raise upload_max_filesize — This controls the maximum single file size PHP will accept.
2. Raise post_max_size — This controls the full POST body size, so it must be larger than upload_max_filesize.
3. Check memory_limit — Some operations need extra memory during processing, even when the upload succeeds.
4. Restart PHP-FPM — If you use PHP-FPM, reload it so the new values take effect.

WordPress also shows an “Maximum upload file size” line in Media settings on many hosts. Treat it as a hint, then verify the real caps in PHP and the web server.

Cloudflare, CDNs, And Managed Proxies

Edge services can block large requests before your origin sees them. If the response headers mention an edge provider, check that provider’s request body limit. Some plans cap uploads at a fixed size.

• Confirm where the 413 comes from — A response server header or edge Ray ID can point to the exact layer.
• Use direct-to-origin uploads — For large media, signed upload URLs to object storage can bypass edge limits.
• Split uploads — Chunked uploads can keep each request under the cap.

If you can’t raise the edge cap on your plan, moving large uploads off the main request path is the clean fix.

Node, Python, And Other App Servers

Many app stacks ship with conservative defaults for request bodies. In Node with Express, body parsing middleware can cap JSON or urlencoded sizes. Python and Ruby stacks can have similar guards.

• Find the parser limit — Search your app for a body size option in middleware or app config.
• Match the reverse proxy limit — Set the app limit at or above the proxy limit, not below it.
• Validate file handling — Stream uploads to disk or object storage instead of buffering huge payloads in RAM.

Raising Limits Without Creating New Problems

It’s tempting to set limits sky-high and move on. That can backfire. Bigger request bodies take longer to transmit, can tie up worker threads, and can be used for denial-of-service attempts. A safer approach is to pick a realistic cap, then build guardrails around it.

Use these habits when you lift a limit.

1. Set a reasoned target size — Base it on the largest file you want to accept, plus overhead for form fields and metadata.
2. Raise timeouts in the same layer — If you allow 200 MB uploads, also ensure proxy_read_timeout and app timeouts won’t cut the connection mid-transfer.
3. Limit by route — Many servers let you set a higher cap only on the upload endpoint, leaving stricter caps elsewhere.
4. Keep authentication in front — Require login or signed URLs for big uploads so anonymous traffic can’t hog resources.
5. Log rejected requests — Store the request size and the rejecting layer so repeat issues are easy to spot.

If your app accepts user files, also think about scanning, file type checks, and storage quotas. A larger upload limit changes your risk profile, so match it with practical controls.

Preventing 413 Errors From Coming Back

Once the upload works, add a few small changes so the same 413 doesn’t pop up again after a plugin update, a server migration, or a new content workflow.

• Show the limit in the UI — Display the max file size near the upload button so users don’t waste time.
• Compress before upload — Resize images, export PDFs with sane settings, and use modern codecs for video when possible.
• Use chunked uploads for big media — Break a large file into parts, retry failed parts, then reassemble server-side.
• Keep backups off the browser — For full-site backups, move transfers to SFTP, object storage, or server-to-server jobs.
• Test after changes — After updates to Nginx, PHP, plugins, or a CDN plan, run one small and one large upload test.

If you keep seeing a 413 error code across multiple users, log the request sizes and compare them to the limits you set. When the failures cluster around a specific threshold, you’ve found the tightest cap in the chain.

Reference Pages You Can Check While Configuring

When you want to confirm directive names and syntax for your stack, these official docs are a safe place to double-check details.

• Nginx documentation — client_max_body_size directive
• Apache documentation — LimitRequestBody directive
• PHP manual — upload_max_filesize and post_max_size
• Cloudflare docs — Error 413 details

After you adjust the limit, run a couple of uploads at different sizes and watch server logs. That quick loop confirms the change applied and points you straight to the next bottleneck if one still exists. That’s it: upload, reload, and carry on all day.