.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
"The uploaded file exceeds the upload_max_filesize directive in php.ini." Everyone hosting on cPanel meets this error eventually, usually while uploading a theme, a backup or a 60 MB video that WordPress flatly refuses. The fix takes two minutes when you use the method your server respects and an afternoon when you don't. Let's do the two-minute version, then cover why changes sometimes refuse to stick.
The settings behind the upload limit
PHP gates uploads with several directives at once, and raising only the famous one is the classic half-fix:
- upload_max_filesize: the ceiling for a single uploaded file.
- post_max_size: the ceiling for the whole POST request. It must be larger than upload_max_filesize, since the request wraps the file plus form fields. Set 64M and 128M respectively and you've got sane headroom.
- memory_limit: how much RAM a PHP process may use. Keep it at or above post_max_size or big uploads die mid-processing.
- max_execution_time and max_input_time: seconds PHP will spend running and parsing input. Slow connections uploading big files need these raised too, 300 is a common choice.
Full definitions live in the PHP core directives manual if you want the fine print.
Method 1: MultiPHP INI Editor (do this one first)
cPanel » Software » MultiPHP INI Editor, Basic Mode tab, pick your domain from the dropdown. You get a form with the exact directives above. Set upload_max_filesize to 64M, post_max_size to 128M, memory_limit to 256M, both time limits to 300, hit Apply.
Behind the scenes cPanel writes these values into the right place for your PHP handler (a php.ini, a .user.ini or the FPM pool as appropriate), which is why this method wins: it knows your server's setup so you don't have to. The Editor Mode tab on the same screen lets you type directives freehand into the INI file if you prefer, same result.
Method 2: a .user.ini file
No MultiPHP INI Editor in your cPanel? Some hosts hide it. Create a file called .user.ini in public_html (File Manager, +File, show hidden files) containing:
upload_max_filesize = 64M
post_max_size = 128M
memory_limit = 256M
max_execution_time = 300
max_input_time = 300This works under CGI, FastCGI, FPM and LSAPI handlers, which covers nearly every cPanel server today. Mind the caching: PHP rereads .user.ini on an interval (user_ini.cache_ttl, 300 seconds by default), so give it five minutes before concluding it failed.
Method 3: php_value in .htaccess (mostly a trap now)
Old tutorials still hand out this snippet:
php_value upload_max_filesize 64M
php_value post_max_size 128MIt only functions when PHP runs as an Apache module (DSO), which modern cPanel servers rarely use. Under FPM or CGI handlers those same lines throw an immediate 500 Internal Server Error on the entire site. If you pasted this and everything broke, delete the lines and breathe; the site returns instantly. I mention the method mainly so you recognize it as the cause of that 500.
Method 4: WHM, for VPS and dedicated owners
Root access changes the game. WHM » Software » MultiPHP INI Editor sets the same directives server-wide per PHP version, so every account inherits the new limits. Per-site overrides still work on top via the account-level editor. If you run PHP-FPM (you should), also look at WHM » MultiPHP Manager to confirm which pool serves the domain; pool-level settings in advanced setups can override the INI values, a fun one to discover after an hour of editing the wrong layer.
On our cPanel VPS plans you get WHM as standard, so this whole article is a two-field edit and there's no ticket to open and no host-side hard cap above you. Server not built yet? Installing cPanel on a VPS is its own half-hour job and we've written it up separately.
The WordPress wrinkle
WordPress reports the limit at Site Health » Info » Media Handling and its uploader enforces whatever PHP says. This bites right after a fresh cPanel WordPress setup, the first time a premium theme zip outgrows the defaults. After raising the values, the media library's "Maximum upload file size" line should show the new number on the next load. If WordPress still shows the old limit, it's caching or you edited a different PHP version than the domain runs (check cPanel » MultiPHP Manager for the actual version, then redo the INI change for that version). Multisite additionally has its own network-level cap under Network Settings, a completely separate ceiling from PHP's.
Verify and troubleshoot
The trustworthy check is phpinfo. Create info.php in public_html with <?php phpinfo();, load it, search the page for upload_max_filesize and read the "Local Value" column. Delete the file right after; a public phpinfo page is a gift to attackers.
When the value refuses to change, it's one of four culprits in my experience, in this order of likelihood. You edited settings for a PHP version the domain doesn't use. An .htaccess php_value line from an old tutorial is overriding or 500-ing things. The .user.ini cache TTL hasn't expired yet. Or, on shared hosting, the provider set a hard limit at the server layer that user-level files can't exceed; that last one ends in a support ticket or an upgrade, no INI file will beat it.
And a limit worth respecting: don't set upload_max_filesize to 2G to move a site backup. Huge uploads through PHP tie up a worker for minutes and fail on any hiccup. Anything over a couple hundred megabytes moves better over SFTP or with cPanel's File Manager upload, which doesn't pass through PHP's limits at all.
