A 413 means a server or another component in the request path considers the request body too large. On a PHP site, check PHP’s upload_max_filesize and post_max_size, plus any limits enforced by NGINX, Apache, a proxy, or your hosting provider. The error alone does not identify which layer rejected the request.
What “413 Request Entity Too Large” means
HTTP 413 is called Content Too Large in RFC 9110. It means the server is refusing to process a request because its content is larger than the server is willing or able to handle. “Request Entity Too Large” is older wording that still appears in server errors and documentation. RFC 9110, Section 15.5.14
For a PHP upload, the request usually passes through several components before PHP handles it. A web server or upstream proxy can reject the request first; PHP or the application can impose further limits later. Raising a PHP setting will not fix a 413 issued by an earlier component.
Which limits can cause a 413?
These settings measure different things and apply at different stages. The documented defaults below are reference values, not evidence of what your site currently uses; software versions, distributions, and hosting configurations can change the active values.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
| Layer | Setting | What it limits | What to check |
|---|---|---|---|
| PHP | upload_max_filesize |
The size of an individual uploaded file. PHP documents a default of 2M. |
Set it high enough for the largest allowed single file. PHP core directives |
| PHP | post_max_size |
The total POST data size, including uploaded files and other fields. PHP documents a default of 8M. It must be larger than upload_max_filesize; when POST data exceeds it, $_POST and $_FILES are empty. |
Allow for the complete multipart request, not just the raw file size. PHP core directives |
| PHP | memory_limit |
Memory available to PHP scripts; it is not a web-server request-body cap. | PHP generally recommends this be larger than post_max_size, with the actual value suited to application workload. PHP core directives |
| NGINX | client_max_body_size |
The maximum client request body. The documented default is 1m; excess requests receive 413. |
Inspect the active http, server, or location configuration for the request. NGINX core module |
| Apache | LimitRequestBody |
The maximum HTTP request body in the applicable configuration context; excess requests receive 413. | Check server, virtual-host, directory, file, or location configuration. Apache mod_request |
| Proxy, gateway, host, or application | Product-specific body or parser limit | May restrict the request before or after it reaches PHP. There is no universal value. | Check the deployed product’s configuration or ask the hosting provider or system operator. |
PHP’s POST method upload documentation describes how PHP handles uploads. The complete request can be larger than the file because a multipart form includes boundaries, headers, and any additional fields.
How to find the component rejecting the request
- Reproduce the problem and note the size. Try a request below and then above the intended limit. Record the approximate total request size, not only the file’s size.
- Inspect the response and logs. A branded error page or response headers can offer a clue, but neither proves the source: a proxy can return its own 413 before the web server or PHP sees the request. Check logs for every component in the request path. NGINX documents a log message for a client sending a body that exceeds its configured limit. NGINX core module
- Check PHP’s web-request configuration. Verify
upload_max_filesizeandpost_max_sizein the configuration used by the web PHP runtime. A command-line PHP configuration may differ. If the request exceedspost_max_size, empty$_POSTand$_FILESarrays are a useful clue that PHP’s POST limit was exceeded. - Check the active web-server rule. For NGINX, find the effective
client_max_body_sizeat the relevanthttp,server, orlocationscope. For Apache, inspect the applicableLimitRequestBodyrule. A more specific configuration may govern the affected endpoint. - Check upstream and application limits. If PHP and the web server allow the request, inspect any reverse proxy, gateway, managed-host setting, and application or framework body parser. If you do not administer these layers, ask the provider which limit applies to the route.
Some gateway products have their own configuration rather than using NGINX’s core directive. For example, NGINX Gateway Fabric documents a 413 troubleshooting case involving its product-specific ClientSettingsPolicy; use that guidance only if NGINX Gateway Fabric is actually in your request path. NGINX Gateway Fabric troubleshooting
Quick Recap
Rank #4
Rank #2
How to raise the limit safely
- Choose the required maximum. Decide the largest legitimate file and total form request your endpoint must accept. Leave room for multipart overhead, but do not set an unlimited size by default.
- Raise the enforcing limits together. Configure the relevant PHP upload and POST limits, then ensure the web server, proxy, gateway, or host allows at least the intended total request size. Keep
post_max_sizelarger thanupload_max_filesize. Treatmemory_limitseparately: it can affect script processing, but cannot override a request-size rejection upstream. - Limit scope where possible. Apply a larger allowance only to the server, route, or upload endpoint that needs it, rather than raising a global limit unnecessarily. Apache cautions that retaining request bodies consumes temporary RAM and recommends limiting the feature to the needed URL space with the lowest adequate value. Apache mod_request
- Apply configuration changes as required by your setup. The method varies by host and deployment. A managed provider may control a limit that you cannot change in a PHP file or local server configuration.
- Retry the same request and verify the result. Confirm the HTTP response and that the application actually received and accepted the file. A removed 413 can expose a later issue, such as execution time, temporary storage, permissions, or application validation; it does not by itself prove that the upload completed.
What to check if changing PHP settings did not help
- The error appears before PHP runs: inspect NGINX, Apache, a proxy, gateway, or hosting limit. PHP settings cannot change a rejection generated earlier in the request path.
- PHP receives empty upload and form arrays: compare the total POST size with
post_max_size, and verify the web runtime’s active configuration. - Small files work but larger ones fail: reproduce around the threshold and compare it with each layer’s configured limit. Do not assume the documented defaults are active on your site.
- The 413 disappears but the upload still fails: check the PHP or application error, execution time, temporary upload storage, filesystem permissions, and application-level validation as separate issues.
- You cannot inspect the rejecting layer: send the provider the approximate request size, endpoint, time of the failed attempt, response details, and any request identifier. Ask which component returned 413 and what maximum applies.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
