Fix the PHP POST Request Capacity Limit Error
You upload an Excel spreadsheet through a PHP form, wait for the request to finish, and receive a server error instead of an import confirmation. A smaller spreadsheet works perfectly, which makes the problem look like a bug in your upload code.
The good news is that you usually don't need to rewrite the uploader. By following these steps, you'll identify which server limit is rejecting the request, adjust the correct setting, and verify that PHP or Laravel can receive the file.
The error often appears as:
Request Entity Too Large
The requested resource does not allow request data
with POST requests, or the amount of data provided
in the request exceeds the capacity limit.The important part is the HTTP status. A 413 Content Too Large response usually means that an incoming request exceeds a configured limit. PHP, Apache, Nginx, a reverse proxy, or a web application firewall may be responsible.
Let's isolate the layer that is failing before changing anything.
1. Reproduce the POST Request Error and Check HTTP Status
First, reproduce the issue with the same file that fails in your application.
Open your browser's developer tools, switch to the Network tab, and submit the upload form. Select the failed request and look at its status code, response body, and request headers.
You can also reproduce an upload using cURL:
curl -i \
-F "sheet=@./largedata.xlsx" \
https://example.com/importReplace the URL with your actual upload endpoint and make sure the spreadsheet exists in your current directory.
The -F option sends the file using multipart/form-data, which is how a standard HTML upload form submits files.
For an oversized request, you might see:
HTTP/1.1 413 Content Too Large
Content-Type: text/htmlThat tells you the request was rejected because of its size, although it does not identify which layer imposed the limit.
Compare the result with a smaller spreadsheet.
If the small file succeeds and the large file gets a 413, you have strong evidence of a request-size restriction.
A different response points elsewhere:
- 405 Method Not Allowed: The endpoint does not accept the HTTP method.
- 413 Content Too Large: A request-body size limit was exceeded.
- 419 in Laravel: Often a missing or expired CSRF token.
- 422 Unprocessable Content: Laravel validation may have rejected the uploaded file.
- 500 Internal Server Error: Investigate application and server logs.
If your Laravel endpoint requires authentication or CSRF protection, a standalone cURL request may return 302 or 419 instead of reaching the upload handler. Use an authenticated browser request for the initial comparison.
Also confirm the route accepts POST:
php artisan route:list --path=importExpected result: Your import route should appear with POST among its supported methods.
2. Inspect the PHP Limits Used by the Website
PHP has two particularly important settings:
upload_max_filesize: Maximum permitted size of an individual uploaded file.post_max_size: Maximum size of the entire POST request body, including files, form fields, and multipart overhead.
The distinction matters. Increasing the individual file limit without allowing enough space for the complete request will not solve the problem.
For a safe diagnostic, create a temporary file named _upload_debug.php in your application's public document root, preferably in a local or access-restricted staging environment.
<?php
header('Content-Type: application/json');
echo json_encode([
'php_sapi' => PHP_SAPI,
'ini_file' => php_ini_loaded_file(),
'post_max_size' => ini_get('post_max_size'),
'upload_max_filesize' => ini_get('upload_max_filesize'),
'memory_limit' => ini_get('memory_limit'),
'max_file_uploads' => ini_get('max_file_uploads'),
'content_length' => $_SERVER['CONTENT_LENGTH'] ?? null,
'post_count' => count($_POST),
'file_count' => count($_FILES),
], JSON_PRETTY_PRINT);Open the diagnostic page through the same website and PHP handler as the failing upload.
For example:
https://example.com/_upload_debug.phpA response might contain:
{
"php_sapi": "fpm-fcgi",
"ini_file": "/etc/php/php.ini",
"post_max_size": "8M",
"upload_max_filesize": "2M",
"memory_limit": "128M",
"max_file_uploads": "20",
"content_length": null,
"post_count": 0,
"file_count": 0
}These are illustrative values; your server may differ.
Now submit a file to that diagnostic endpoint:
curl -i \
-F "sheet=@./largedata.xlsx" \
https://example.com/_upload_debug.phpIf the request reaches PHP and exceeds post_max_size, PHP normally leaves $_POST and $_FILES empty. The diagnostic may therefore show zero files despite receiving a nonzero CONTENT_LENGTH.
If the web server rejects the request first, the diagnostic script will never execute.
This behavior is documented in the PHP configuration manual.
One trap is checking only the command-line configuration:
php --iniThat command shows PHP's CLI configuration, which may differ from the web server's PHP configuration. The browser-accessed diagnostic is more relevant.
Keep the diagnostic page private and remove it when testing is complete.
3. Set Compatible PHP Upload and POST Limits
Once you have confirmed that PHP's configured limits are too small, edit the active php.ini file.
For an application that needs to accept individual Excel files up to 32 MiB, a reasonable example is:
file_uploads = On
upload_max_filesize = 32M
post_max_size = 40M
memory_limit = 128M
max_file_uploads = 20These values are an example configuration, not universal recommendations.
post_max_size is deliberately larger than upload_max_filesize. The additional space accommodates normal form fields and multipart encoding overhead.
If a form accepts multiple files, calculate the total expected request size rather than sizing the POST limit for one file.
For PHP-FPM installations where per-directory configuration is supported, you may instead be able to use a .user.ini file in the applicable directory:
upload_max_filesize = 32M
post_max_size = 40MChanges to .user.ini files may take time to become effective because PHP caches them.
With Apache running PHP as a module, .htaccess can also support:
php_value upload_max_filesize 32M
php_value post_max_size 40MHowever, do not copy those php_value directives into .htaccess on a PHP-FPM or CGI installation. They generally do not work there and can cause an HTTP 500 error if Apache does not recognize them.
Use your hosting panel's PHP configuration editor when that is the supported method.
After updating the configuration, reload or restart the relevant PHP service using your hosting environment's documented procedure.
Then refresh the temporary diagnostic page.
Expected result: PHP reports 32M for upload_max_filesize and 40M for post_max_size.
If those values are correct but the 413 error remains, another layer is likely rejecting the request.
4. Increase Apache or Nginx Request Body Limits
Web servers can reject oversized requests before PHP receives any data. That is why changing php.ini sometimes appears to accomplish nothing.
Apache: Check LimitRequestBody
Apache supports the LimitRequestBody directive.
For example, add the following inside the appropriate virtual host configuration:
LimitRequestBody 50331648This allows request bodies up to 48 MiB.
The value is expressed in bytes, not megabytes. For the example above, Apache's limit is larger than PHP's 40 MiB POST limit.
Apache also permits this directive in eligible directory and .htaccess contexts, depending on the server configuration and permissions.
Check the configuration before reloading Apache:
sudo apachectl configtestOn a typical Debian or Ubuntu installation, reload it with:
sudo systemctl reload apache2Expected result: The configuration test reports Syntax OK, and Apache reloads without errors.
The service name and command may differ on other operating systems.
Apache documents this directive in its core module reference.
Nginx: Check client_max_body_size
For Nginx, add the following directive in the applicable server or location block:
client_max_body_size 48m;Then validate the configuration:
sudo nginx -tIf the validation succeeds, reload Nginx:
sudo systemctl reload nginxExpected result: Nginx accepts the updated configuration and no longer rejects requests solely because they exceed the previous body-size limit.
The Nginx documentation confirms that this directive controls the maximum permitted client request body.
If you use Nginx in front of Apache, both layers need compatible limits. Raising one does not override the other.
The same applies to CDNs, load balancers, and managed reverse proxies: their request limits may be independent and not adjustable from your PHP application.
5. Investigate ModSecurity and Shared Hosting Restrictions
If PHP and the web server limits are correct, inspect the security layer.
This is particularly important on shared hosting, where ModSecurity rules can reject requests independently of PHP.
Search the Apache error log for request-size violations:
sudo grep -Ei \
'ModSecurity|request body|413' \
/var/log/apache2/error.logFor Nginx, check its error log:
sudo grep -Ei \
'too large body|413' \
/var/log/nginx/error.logThese paths are common on Debian-based servers; hosting panels and other distributions may use different locations.
One possible ModSecurity message is:
Request body no files data length is larger
than the configured limitModSecurity distinguishes between total request-body limits and request data excluding uploaded file contents.
Its directives include:
SecRequestBodyLimit 50331648and:
SecRequestBodyNoFilesLimit 1048576The first example allows a larger overall request body. The second separately controls non-file request data.
These belong in the appropriate ModSecurity configuration, not ordinary PHP settings, and should only be adjusted when the logs establish that they are responsible.
Don't disable ModSecurity globally just to make an upload succeed. That removes useful request filtering and can conceal the real cause.
For shared hosting, you may not have access to Apache, Nginx, or ModSecurity configuration.
In that situation, send your hosting provider the failing URL, approximate request size, HTTP status, and relevant log entry. Ask which request-body limit is rejecting the upload and whether a targeted increase is supported.
This was also the key distinction in the Stack Overflow discussion that prompted this issue: changing PHP upload settings did not necessarily remove the limit enforced elsewhere.
6. Handle Large Uploads Correctly in Laravel
Laravel has its own request handling and validation behavior.
Its ValidatePostSize middleware can throw a PostTooLargeException when the declared request size exceeds the configured PHP POST limit.
But Laravel cannot override an upstream Apache, Nginx, or ModSecurity rejection.
Once the request reaches Laravel, validate the uploaded file before storing or processing it.
In routes/web.php:
<?php
use Illuminate\Support\Facades\Route;
use App\Http\Controllers\ImportController;
Route::post('/import', [
ImportController::class, 'store'
]);In app/Http/Controllers/ImportController.php:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class ImportController extends Controller
{
public function store(Request $request)
{
$request->validate([
'sheet' => [
'required',
'file',
'mimes:xlsx,xls',
'max:32768',
],
]);
$path = $request->file('sheet')
->store('imports', 'local');
return response()->json([
'message' => 'Upload successful',
'path' => $path,
]);
}
}For file validation, Laravel interprets the max value in kilobytes, so 32768 represents 32 MiB.
The controller validates and stores the spreadsheet. It does not yet import worksheet rows into a database; that would be a separate processing step.
For a browser form using Laravel's web middleware, include the CSRF token:
<form method="POST"
action="/import"
enctype="multipart/form-data">
@csrf
<input type="file"
name="sheet"
accept=".xlsx,.xls"
required>
<button type="submit">
Upload spreadsheet
</button>
</form>This example is a Blade template, so @csrf must be rendered by Laravel rather than served as plain HTML.
Expected result: A permitted Excel file reaches the controller, passes validation, and is saved to the configured local filesystem disk.
If the request fails at PHP's POST limit, Laravel validation cannot examine the file. If it passes the infrastructure limits but fails the Laravel size rule, Laravel returns a validation error instead.
Why the error can persist after these fixes
A few related problems deserve a separate check:
- Multiple uploaded files: Their combined size and multipart overhead must fit within
post_max_size. - Large JSON requests: JSON is still request-body data; ModSecurity's non-file limit may apply.
- Empty
$_FILES: Often indicates PHP rejected the full POST body, rather than a missing HTML input. - Too many uploaded files: Check
max_file_uploads, which controls file count rather than total request size. - Slow connections: Investigate
max_input_time, server timeouts, and proxy behavior if uploads time out instead of returning 413. - Excel imports failing after upload: Spreadsheet parsing can exhaust memory or execution time even after the upload itself succeeds.
Increasing memory_limit is not a substitute for correcting post_max_size. Similarly, changing max_input_vars does not increase the allowed HTTP request-body size.
Quick Verification: Confirm the Upload Reaches PHP
After changing only the settings responsible for the failure, upload both a small spreadsheet and the original larger file through your real application.
For a diagnostic endpoint that does not require authentication, you can repeat:
curl -i \
-F "sheet=@./largedata.xlsx" \
https://example.com/_upload_debug.phpCheck that the response is no longer 413 and that the diagnostic reports the expected number of uploaded files.
Then test your actual Laravel or PHP upload form. A successful storage response confirms that the request passed through the relevant infrastructure and application layers.
Finally, remove the temporary diagnostic file:
rm public/_upload_debug.phpUse the equivalent path if your document root is different.
For a production application, I would also test a file just above the intended application limit. The ideal behavior is a controlled rejection, not an unlimited upload allowance. Server limits should protect your infrastructure while application validation provides a useful error message to the user.
Next Steps
Once uploads work reliably, keep the request limits only as large as your application needs. For spreadsheet imports, consider storing the uploaded file first and processing its rows in a background queue, especially when imports may involve substantial data. That separates request-body size problems from slower database and spreadsheet-processing work, making future failures much easier to diagnose.
