A 20 MB file can be below upload_max_filesizeand still fail because the complete multipart request exceeds a 16 MB post_max_size. PHP may reject the body before WordPress receives either the file or the accompanying fields.
Treat individual file size and total request size as separate limits, then account for every upstream layer in the same upload path.
What it means
upload_max_filesizelimits one file accepted by PHP. post_max_sizelimits the entire POST body, including all files, form fields and multipart overhead.
Every file must fit the first value, while the combined request must fit the second. Web servers, proxies, WordPress and application code can impose lower ceilings of their own.
A realistic WordPress example
A media form allows a 20 MB video under the individual PHP setting, but its complete request is larger than the total POST allowance. The form arrives empty and the user sees an unhelpful validation error.
The team verifies both active values in the web handler, gives the total limit measured headroom and tests one large file as well as several medium files.
Why it matters and when to use it
Understanding the two scopes prevents repeated changes to the wrong directive. It also explains why multi-file uploads can fail when every individual file appears valid.
Increase limits only for a defined upload need whose storage, processing time and security impact are acceptable. Large bulk workflows may be better split into batches.
A straightforward route for beginners
- Record each file size, the number of files and the other form data.
- Check effective
upload_max_filesizeandpost_max_sizein the failing web context. - Identify lower WordPress, proxy, web-server or hosting limits.
- Choose an individual ceiling that covers the required file.
- Set a larger total allowance with room for all files, fields and multipart overhead.
- Test a boundary file and a multi-file request through the real form.
The advanced route
Inspect PHP warnings and raw response behavior when the POST body is rejected. An empty the parsed POST and file arrays can be a more useful clue than the application message.
Compare FPM pool or handler configuration with CLI values and trace body-size controls at the CDN, proxy and web server. Do not assume a changed php.iniis loaded by the affected request.
Risks, common mistakes, backup, and rollback
Large request allowances increase memory, temporary-storage and processing exposure. Raising PHP values cannot overcome an upstream 413 or insufficient disk space.
Record the former settings and verify normal uploads after the change. Roll back if resource pressure rises or the provider refuses the intended values, then reduce or redesign the workload.
How AIOWS helps:
AIOWS PHP Limits
AIOWS PHP Limits can display the effective per-file and total POST limits together, attempt server-supported changes and help verify the resulting values. Review both file and POST limits together in the WordPress web context.
Request a coherent pair with measured total headroom, note the requested and effective values, then exercise both single- and multi-file boundaries. A changed setting is useful only when the real form succeeds.
The server may reject an override, and AIOWS cannot raise a proxy body limit or provide storage capacity. Resolve whichever lower layer still controls the upload.
Related AIOWS articles
- Increase WordPress Upload Size: Complete Limit Guide
- How to Increase PHP max_input_vars for WordPress
- 413 Request Entity Too Large in WordPress: How to Fix It
Conclusion and recommended route
Plan for two PHP scopes: each file and the complete POST body. Give the total request enough measured headroom, verify both settings in the web handler and test the public upload route end to end.
