Free tools Windows power users keep installed
One-click scans. No signup required.
If PHP still reports the old upload limit after you edit php.ini, the usual cause is not a bad number. The web request is probably using a different PHP configuration, the owning service has not been reloaded, or Nginx or Apache is rejecting the request before PHP sees it. Fix the entire request path: verify the web SAPI’s active configuration, set upload_max_filesize and a larger post_max_size, align any web-server limit, reload the correct processes, and test with an actual browser request.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What “maximum upload size” means in PHP
There is no single PHP setting that controls every upload. Several limits apply at different layers, and the smallest applicable limit wins.
As an Amazon Associate I earn from qualifying purchases.
| Setting | What it limits | Documented default | Important behavior |
|---|---|---|---|
upload_max_filesize |
One uploaded file | 2M |
A file larger than this is rejected by PHP’s upload handling. |
post_max_size |
The complete HTTP POST body, including all files and ordinary form fields | 8M |
It must be larger than upload_max_filesize. If the body exceeds it, PHP leaves both $_POST and $_FILES empty. |
max_file_uploads |
How many files one request may upload | 20 |
This is a file-count limit, not a byte limit. |
memory_limit |
PHP memory available while processing the request | Build- and version-dependent | It should generally be higher than post_max_size, although an application does not necessarily keep the entire request in memory at once. |
A practical planning order is memory_limit > post_max_size > upload_max_filesize. This is a sizing rule, not a guarantee: an application, reverse proxy, control panel, or hosting provider can impose a lower limit.
Why an 8 MB setting can still reject a 7 MB file
post_max_size includes the multipart form overhead and every other field in the request. Several files are counted together. Therefore, a 7 MB file in an 8 MB POST leaves little room for boundaries, filenames, text fields, and other metadata. Set the POST limit comfortably above the largest intended request, not merely one byte above the largest file.
#1 Best Overall
Why editing php.ini appears to do nothing
The file you edited belongs to the CLI, not the web server
PHP can load separate configuration files for the command-line interface (CLI), CGI, PHP-FPM, and an Apache module. Running php --ini in a terminal reports the CLI binary’s files. It does not prove that a browser request uses the same binary or configuration.
The PHP manual describes the configuration file as being read when PHP starts. A server-module installation therefore keeps its values until the web server is restarted or gracefully reloaded. CGI and CLI processes read configuration at each invocation, while a long-running PHP-FPM pool keeps the values loaded by its worker process until that pool is reloaded or restarted.
The owning process was never reloaded
Even when you edit the right file, existing workers can continue using the old values. Reload or restart the process that actually reads the file: the relevant PHP-FPM service or pool, Apache when PHP is an Apache module, and Nginx after changing Nginx configuration. Recheck through a browser request; a second terminal command can still be showing the wrong SAPI.
Nginx rejects the request before PHP receives it
Nginx’s client_max_body_size limits the client request body before PHP runs. Its documented default is 1m. If the request exceeds the configured value, Nginx returns HTTP 413 (Request Entity Too Large), so PHP cannot apply upload_max_filesize or produce a PHP upload error. Setting client_max_body_size 0; disables that Nginx size check, although PHP and application limits still apply.
Apache imposes an independent request-body limit
Apache’s LimitRequestBody can restrict the request body at server, virtual-host, directory, file, or location scope. Apache documents a value of 0 as unlimited. A value inherited from a virtual host or directory can override what you expect from PHP, so inspect every applicable scope.
Rank #2
A pool, application, or hosting policy overrides PHP
PHP-FPM pools can apply administrative overrides, and managed hosting accounts may enforce caps outside your editable php.ini. An application may also validate file size itself. If the web diagnostic shows the intended PHP values but the upload still fails, inspect the FPM pool definition, virtual-host configuration, application settings, reverse-proxy policy, and provider documentation.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsVerify the configuration used by a real web request
Do not guess which file is active. Create a temporary diagnostic endpoint in a protected location and request it through the same hostname and protocol as the upload form. A minimal PHP page can report the SAPI, loaded files, and effective values:
<?php
header('Content-Type: text/plain');
echo 'SAPI: ' . PHP_SAPI . "n";
echo 'Loaded php.ini: ' . (php_ini_loaded_file() ?: '(none)') . "n";
echo 'Scanned .ini files: ' . (php_ini_scanned_files() ?: '(none)') . "n";
foreach ([
'upload_max_filesize',
'post_max_size',
'memory_limit',
'max_input_time',
'max_file_uploads'
] as $name) {
echo $name . ': ' . ini_get($name) . "n";
}
?>PHP_SAPI tells you whether the request is using FPM, an Apache module, CGI, or another interface. php_ini_loaded_file() identifies the primary file; php_ini_scanned_files() reveals additional files that may change a value later in the load order. Compare those results with the file you edited.
- Access the page only over an authenticated or IP-restricted path.
- Never leave unrestricted
phpinfo()output on a public site; it exposes paths, modules, and environment details. - Delete the diagnostic script, or disable it, immediately after troubleshooting.
Repeatable fix: align every layer
1. Record the failure and HTTP status
Try the upload once and note the exact response. HTTP 413 strongly indicates Nginx, a proxy, or Apache rejected the body before PHP. A PHP warning, an upload error code, or an application-generated message means the request reached PHP or the application. Browser developer tools, the web-server error log, and the PHP/application log can distinguish these cases.
2. Measure the web SAPI’s effective values
Use the protected diagnostic page above. Record PHP_SAPI, the loaded and scanned configuration files, and the effective values for upload_max_filesize, post_max_size, memory_limit, max_input_time, and max_file_uploads. This prevents changing a file that the upload path never reads.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall3. Set PHP’s per-file and request limits
Edit the file identified by the web diagnostic, or the pool-level configuration that controls that SAPI. For example:
upload_max_filesize = 64M
post_max_size = 70M
memory_limit = 128M
max_file_uploads = 20The exact values should match your application’s needs. The essential relationship is that post_max_size is higher than upload_max_filesize, with room for form data and multipart overhead. Keep memory_limit appropriately higher than the complete POST limit. PHP accepts size suffixes such as K, M, and G; use the syntax supported by your PHP version and keep units consistent.
4. Raise Nginx’s request-body limit when Nginx is in the path
Place the directive at the narrowest scope that covers the upload endpoint: http, the relevant server, or a specific location. For a 64 MB file and a 70 MB POST setting, allow at least the full request size:
client_max_body_size 70m;Validate before reloading:
nginx -t
nginx -s reloadThe reload sends Nginx a SIGHUP so it rereads its configuration without needlessly discarding active connections. If the test fails, correct the reported syntax or include-file error before reloading. A 413 after a successful reload usually means another proxy or a more-specific Nginx scope still has a lower value.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →5. Check Apache’s LimitRequestBody
Search the Apache main configuration, virtual-host definition, directory blocks, file or location sections, and included snippets. A byte value must be at least as large as the complete POST you intend to accept. For unlimited request-body size at a scope where that is appropriate:
Rank #4
LimitRequestBody 0Use an explicit finite value when possible, because unlimited request bodies increase resource and denial-of-service exposure. Apply the configuration with the normal graceful reload or restart for your Apache installation, then test through the browser.
6. Reload PHP-FPM or Apache
Reload or restart the PHP-FPM service and, when applicable, the specific pool serving the site. For an Apache PHP module, gracefully reload or restart Apache. Service names and commands differ by operating system and package, so use the service manager’s command for your installation. Reload Nginx separately if its configuration changed; reloading Nginx does not reload PHP-FPM workers.
7. Recheck and run controlled boundary tests
Open the diagnostic endpoint again and confirm the new values. Then perform two uploads: one comfortably below the intended threshold and one just above it. Record the HTTP status, PHP error, and application response. A below-limit success followed by the expected failure above the limit confirms that the active layer is enforcing the value you intended.
8. Remove diagnostics and restore least privilege
Delete the temporary page, remove any temporary public access rule, and retain finite limits that fit the application. Do not leave a publicly accessible configuration dump or an unlimited body-size setting merely because it made testing easier.
How the common deployment stacks differ
| Stack | Process that reads configuration | Earlier request-body limit | Reload action | Best verification |
|---|---|---|---|---|
| CLI PHP | The CLI binary reads its configuration for each invocation | None from a web server, unless a script or client imposes one | Run the command again | php --ini and CLI output; this does not verify browser requests |
| Nginx + PHP-FPM | PHP-FPM workers read PHP settings when the pool starts | Nginx client_max_body_size; default 1m |
Reload PHP-FPM and Nginx independently | Protected web diagnostic plus Nginx status/logs |
| Apache + PHP module | Apache loads the module and PHP configuration when Apache starts | Apache LimitRequestBody at the applicable scope |
Gracefully reload or restart Apache | Protected web diagnostic plus Apache logs |
| CGI or another FastCGI arrangement | The CGI/FastCGI process and its startup environment | Front-end server or proxy may reject the body first | Restart the relevant workers and reload the front end | Web diagnostic, front-end logs, and the actual response status |
Diagnose the number shown in the error
“The limit is 2 MB”
2M is PHP’s documented default for upload_max_filesize. It limits an individual file. If your web diagnostic still shows 2M, you changed the wrong configuration or did not reload the owning process. If it shows a larger value, an application, FPM pool, Apache, proxy, or hosting policy may be enforcing the 2 MB ceiling instead.
“The limit is 8 MB” or fields are empty
8M is PHP’s documented default for post_max_size. Because it covers the entire POST, a request can fail even when the file itself is smaller than upload_max_filesize. When PHP receives a body larger than post_max_size, both $_POST and $_FILES are empty; an application that assumes a missing file may display a misleading validation message.
“The limit is 1 MB” and the response is 413
Nginx’s documented default client_max_body_size 1m; commonly produces this symptom. Raise the directive at the effective scope, validate with nginx -t, reload Nginx, and check for another proxy or location block with a lower value. PHP cannot override a request that never reaches it.
Recommended Free Tools
When the size settings are correct but uploads still fail
Input processing takes too long
max_input_time limits how long PHP spends parsing input, including an upload. Slow connections, large files, or busy servers can exceed it even when the byte limits are sufficient. Increase it only as far as the application requires, and also inspect proxy, load-balancer, and web-server read timeouts.
The temporary upload directory is unavailable
PHP first writes uploaded data to a temporary directory. If upload_tmp_dir is unset, points to a nonexistent path, lacks write permission for the PHP worker, or the filesystem is full, uploads fail independently of the configured maximum. Check the path, ownership, permissions, mount status, and free space. Correct the problem without making the directory world-writable.
Too many files are submitted
The documented default for max_file_uploads is 20. A request containing more files can fail even when each file and the combined POST are below their byte limits. Raise the count only when the application genuinely needs it and validate the number server-side.
The application has its own validation
Content-management systems, frameworks, and custom handlers often apply a lower per-file or total limit. They may also reject extensions, MIME types, image dimensions, archive contents, or user roles. Once PHP and the front end show the intended values, inspect the application’s upload validation and its logs rather than continuing to edit php.ini.
A reverse proxy or hosting provider enforces a cap
Traffic can pass through a proxy, gateway, control panel, or managed-host policy before reaching Nginx, Apache, or PHP. A proxy-generated 413, an unchanged limit after every local reload, or a setting that reverts after deployment points to that layer. Identify the component from response headers and logs, then change the policy there or ask the provider for the account’s permitted maximum.
Security and capacity considerations
- Large request limits allow clients to consume bandwidth, disk, worker time, and memory. Set a finite value close to the largest legitimate upload.
- Keep
post_max_sizeonly modestly above the intended request size; making it many gigabytes “just in case” magnifies abuse and operational risk. - Use authentication, authorization, filename handling, MIME verification, and storage isolation in addition to size checks.
- Monitor temporary-directory usage and cleanup behavior when accepting large or numerous files.
- Apply configuration changes consistently across all web nodes; a load-balanced site can appear intermittent when nodes have different limits.
A compact decision path
- If the response is HTTP 413, inspect Nginx, Apache, and any proxy before PHP.
- If PHP reports a size error, verify the web SAPI’s loaded file and effective directives.
- If the diagnostic values are old, edit that file or pool and reload the owning process.
- If values are correct but the upload fails, check
max_input_time, temporary-directory health, file count, application validation, and provider policy. - Confirm with a below-limit and above-limit browser upload, then remove diagnostic access.
Following this order separates configuration problems from front-end rejection and application policy. It also explains why a successful php --ini check alone cannot prove that a website is using the values you changed.
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.
