A media editor tries to upload a 40 MB video, but WordPress reports a 16 MB maximum. Changing upload_max_filesizeto 64 MB still does not help: post_max_sizeis lower, and a reverse proxy rejects the request before PHP receives it.
The effective upload limit is the lowest ceiling anywhere on that request path. Record the exact file, error, and active values before making a change. Then raise only the controlling limit, leave enough room for the complete request, and repeat the same upload.
What it means
The maximum shown by WordPress is derived from several possible limits. upload_max_filesizeapplies to one file, while post_max_sizecovers the entire multipart request, including form fields and overhead. WordPress or Multisite can impose a lower policy, and a web server, WAF, proxy, CDN, or hosting plan may reject the body earlier.
The accepted size is therefore the smallest active limit, not the largest value found in a settings screen. Media uploads, plugin ZIP files, imports, REST requests, and backup restores may also follow different paths and should be tested separately.
A realistic WordPress example
WordPress displays a 16 MB media limit. The administrator raises both PHP values, keeping post_max_sizeabove the intended file size, but a 40 MB upload still returns HTTP 413 and no PHP log entry appears. The reverse proxy is still capped at 32 MB.
After the hosting team raises that limit to the agreed value, a 39 MB control video uploads and completes metadata processing. A file just above the new ceiling is rejected as expected, while a small image and an ordinary page request remain unaffected.
Why it matters and when to use it
Increase the limit only for a legitimate workflow that has adequate temporary space, permanent storage, processing time, memory, and security controls. A failed upload can instead be caused by file type policy, permissions, quota, malware scanning, timeout, or media processing.
A measured ceiling is safer than an unrestricted one. It reduces accidental storage consumption and narrows the effect of compromised accounts. If the file is exceptional rather than routine, an external video or object-storage workflow may be more appropriate than raising every WordPress upload path.
A straightforward route for beginners
- Record the file’s exact byte size and type, the WordPress-reported maximum, and the response or error message.
- Check active
upload_max_filesizeandpost_max_size; leave room in the latter for the full multipart request. - Determine whether PHP receives the request. A 413 with no PHP entry points to the web server, proxy, WAF, CDN, or provider.
- Change the lowest controlling limit through the system or provider that owns it and leave unrelated memory or execution settings alone.
- Repeat the target upload, a file just below and above the limit, and a small control upload. Confirm that WordPress finishes processing the accepted file.
The advanced route
Build a limit map from the public endpoint to storage: edge or CDN body limit, proxy, web server, PHP request total, PHP file limit, WordPress or Multisite policy, temporary directory, final storage, and post-upload processing. Note the active value and owner at each step.
Use the same authenticated route and inspect the status, response source, PHP and server logs, disk quota, and processing result. A value used by CLI or a different PHP-FPM pool does not prove that the web request uses the same configuration.
Risks, common mistakes, backup, and rollback
Do not stack conflicting directives in php.ini, .user.ini, .htaccess, and wp-config.php. That makes the active owner difficult to identify and complicates rollback. Back up any file before editing it and record the previous requested value.
Restore the former setting if the server rejects the change, upload processing becomes unstable, disk use grows unexpectedly, or users can submit files outside the intended policy. Reducing file size or changing the workflow is a valid outcome when an upstream ceiling cannot safely be raised.
How AIOWS helps:
AIOWS PHP Limits
AIOWS PHP Limits displays the active PHP values visible to the current WordPress installation. This helps determine whether upload_max_filesizeor post_max_sizeis the PHP-side constraint and whether a saved change became effective.
When the server environment permits, the module can attempt supported limit changes. Set a measured pair, check the effective values again, and repeat the same file upload through the web interface.
AIOWS cannot raise a web-server, proxy, CDN, Multisite, or hosting-plan ceiling, and it cannot guarantee that a provider accepts an override. If PHP never receives the request or the active value does not change, use the responsible system’s supported configuration or reduce the payload.
Related AIOWS articles
- How to Fix Maximum Execution Time Exceeded in WordPress
- post_max_size vs upload_max_filesize in WordPress
- 413 Request Entity Too Large in WordPress: How to Fix It
Conclusion and recommended route
Find the lowest verified ceiling on the actual upload path. Raise that limit through the system or provider that owns it, keep post_max_sizeabove the whole request, and retest the same payload. Accept the change only when WordPress processes the file and storage, timeout, and security behavior remain healthy.
