A 413 Request Entity Too Large response means a component on the request path rejected the body because it exceeded the size it is willing or able to process. On a PHP site, changing PHP alone may not help: check PHP’s upload_max_filesize and post_max_size, plus NGINX, Apache, reverse-proxy, gateway, and hosting limits. The active limit is deployment-specific.
What HTTP 413 means
HTTP 413 is currently named Content Too Large in RFC 9110. “Request Entity Too Large” is the older wording that remains in server documentation and error pages. The status means the rejecting server considers the request content larger than it is willing or able to process; it does not identify which component made the decision. See RFC 9110, section 15.5.14.
The rejected content is the entire request body, not necessarily just the file. A multipart form can include field values and multipart boundaries, so a file near your configured limit can make the total POST larger than expected.
Which layer is enforcing the limit?
| Layer | Setting | What it counts or does | Documented default or behavior |
|---|---|---|---|
| PHP | upload_max_filesize |
Maximum size of one uploaded file | 2M is PHP’s documented default; inspect the active web configuration at the PHP core-directives manual. |
| PHP | post_max_size |
Maximum POST data, including uploads and other multipart fields | 8M is the documented default. It must be larger than upload_max_filesize; oversized POST data leaves $_POST and $_FILES empty. |
| PHP | memory_limit |
Memory available while PHP processes the request | PHP generally recommends a value larger than post_max_size. It is not a replacement for an upstream body-size limit. |
| NGINX | client_max_body_size |
Maximum client request body | The documented default is 1m. It can be set in http, server, or location context; an excess returns 413. See NGINX’s directive documentation. |
| Apache | LimitRequestBody |
Maximum HTTP request body in the applicable configuration context | Apache returns 413 when the request exceeds the configured value. See Apache mod_request documentation. |
| Proxy or gateway | Provider-specific body-size policy | Request body before it reaches your web server or PHP | Not stated universally; inspect the product or hosting documentation and its logs. |
These are documentation defaults, not guarantees about your server. Distribution packages, virtual hosts, containers, control panels, CDNs, and managed hosts can override them.
#1 Best Overall
How to diagnose the rejecting component
- Define the intended request size. Reproduce the failure with a file just below and then just above the target size. Record the approximate total POST body, allowing room for multipart overhead and other fields.
- Identify the response producer. Look at the response page, headers, and server logs. NGINX-branded output or its logged message about a client sending a body that is too large points toward NGINX, while a gateway or proxy may reject the request before your server sees it. NGINX Gateway Fabric shows a product-specific 413 troubleshooting example at its troubleshooting guide.
- Check PHP’s web runtime. Inspect the PHP configuration used by the web request, not merely a command-line PHP installation. Verify both
upload_max_filesizeandpost_max_size. The latter must exceed the former and must cover the complete multipart request. - Check NGINX’s effective context. Find the active
client_max_body_sizein the matchinghttp,server, andlocationconfiguration. A value in another virtual host or location may not apply to the upload endpoint. - Check Apache when it is in the path. Inspect
LimitRequestBodyat server, virtual-host, directory, file, or location scope. A restriction there can reject the request before PHP runs. - Check upstream infrastructure and application parsing. Review reverse-proxy, gateway, CDN, hosting-control-panel, and framework body-parser policies. If PHP and the web server accept the body but the application still fails, inspect application validation, temporary storage, permissions, and execution-time handling.
Set compatible limits for PHP uploads
Choose the request size, not just the file size
Start with the largest legitimate file and add room for multipart overhead and any accompanying fields. Set post_max_size above that total, and set upload_max_filesize at or below the largest individual file you intend to accept. PHP’s upload guidance is documented at POST method uploads.
Align every upstream limit
The smallest active limit wins. For example, increasing PHP to accept a 20 MB file cannot help if NGINX still has a 1 MB client_max_body_size, or if a hosting gateway rejects the request first. Configure the narrowest relevant endpoint when possible rather than raising a global limit for every request.
Keep the bound deliberate
Do not set an unlimited body size reflexively. Large requests consume connection, buffering, temporary-storage, and application resources. Apache cautions that retained request data uses temporary RAM and recommends limiting the feature to the required URL space with the lowest adequate value. A bounded limit also reduces exposure to deliberately oversized requests.
Why changing PHP may appear to do nothing
- Another layer rejected first: NGINX, Apache, a reverse proxy, gateway, CDN, or managed host can return 413 before PHP receives the request.
- The wrong PHP configuration was edited: command-line PHP and the web server can use different ini files or runtimes.
post_max_sizeis too small: the file may fit underupload_max_filesize, while the complete POST does not. PHP then exposes empty$_POSTand$_FILES.- A later failure was exposed: after the size limit is raised, the request may reach a timeout, storage, permission, validation, or application-processing problem. A changed symptom does not prove that the upload completed.
Verify the fix safely
- Apply the smallest values that accommodate the intended total request at each active layer.
- Reload or restart the relevant service according to your deployment method, then confirm the effective configuration in the matching host and endpoint.
- Repeat the same below-limit and above-limit requests.
- Confirm the HTTP response, that PHP receives populated upload data, and that the application stores and validates the file successfully.
- Review logs again if the result changes from 413 to another error; that usually means the request passed the body-size gate and reached a later processing stage.
Frequently asked questions
Is 413 always caused by PHP?
No. It can be generated by NGINX, Apache, a proxy, gateway, CDN, or hosting platform before PHP handles the request.
Rank #3
Should post_max_size be equal to upload_max_filesize?
No. post_max_size must be larger because it covers the complete POST body, including the uploaded file, multipart overhead, and other fields.
Does increasing memory_limit fix 413?
Not by itself. Memory affects PHP’s processing capacity; a web server or upstream component can still reject the request-size limit before PHP runs.
Quick Recap
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.
