If you've ever tried to upload a large media file, a plugin zip, or a database dump in cPanel or WordPress and hit a wall with "The uploaded file exceeds the upload_max_filesize directive" or WordPress's blunter "File exceeds the maximum upload size for this site," you're not dealing with a broken feature. You're bumping into a PHP configuration limit, and there's a right way and a wrong way to raise it.

This one trips people up because the obvious fixes — editing wp-config.php, adding a random line to .htaccess someone found in a forum thread — often do nothing at all, depending on how PHP is running on your account. Here's how to actually fix it.

Symptom

You'll see one of a few variations depending on where the upload happens:

  • The uploaded file exceeds the upload_max_filesize directive in php.ini — usually thrown by PHP itself before WordPress even gets involved.
  • File exceeds the maximum upload size for this site. — WordPress's own media library message.
  • A blank or generic error when uploading a plugin/theme zip, or when restoring a large SQL file through phpMyAdmin.
  • Softaculous or a WooCommerce product import silently truncating a CSV instead of erroring cleanly.

Cause: it's a stack of PHP directives, not one setting

Upload size in PHP isn't governed by a single value. Three directives interact, and if any one of them is too low, the upload fails even if the others are generous:

DirectiveWhat it controlsTypical shared hosting default
upload_max_filesizeMax size of a single uploaded file2M – 64M
post_max_sizeMax size of the entire POST request (must be >= upload_max_filesize)8M – 64M
memory_limitMax memory a PHP script can use while processing the upload128M – 256M
max_execution_timeHow long the script can run — matters for slow uploads, not size directly30 – 300s

The most common mistake we see: someone raises upload_max_filesize to 512M but leaves post_max_size at 64M. The file is still rejected, because the whole request (file plus form fields plus overhead) can never exceed post_max_size. Set post_max_size a bit higher than upload_max_filesize, always.

Fix 1: MultiPHP INI Editor in cPanel (do this first)

This is the cleanest fix for shared and reseller hosting, and it works regardless of whether your account runs PHP as an Apache module, suPHP, or PHP-FPM:

  1. Log in to cPanel and open MultiPHP INI Editor under the Software section.
  2. Select your domain from the dropdown.
  3. Switch to Editor Mode (not the basic mode — the directives you need aren't exposed there).
  4. Update these lines (add them if missing): 
    upload_max_filesize = 256M
post_max_size = 300M
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
  5. Click Save. No restart is needed — it applies to the next request.

Don't go overboard with these numbers. Setting upload_max_filesize to an absurd value like 2G on shared hosting can get flagged by your provider's resource limits, and it does nothing for you if your hosting plan's disk quota can't hold the file anyway.

Fix 2: user.ini or php.ini in File Manager (when MultiPHP INI Editor isn't available)

If you're on a VPS running your own PHP-FPM pools, or your cPanel plan doesn't expose MultiPHP INI Editor, edit the file directly:

  • PHP-FPM with per-directory .user.ini support: create or edit public_html/.user.ini: 
    upload_max_filesize = 256M
post_max_size = 300M
memory_limit = 512M
    Changes to .user.ini are picked up within the user_ini.cache_ttl window, usually 5 minutes — not instantly.
  • Dedicated VPS with a single PHP-FPM pool: edit the pool's php.ini directly (commonly /etc/opt/remi/php8.2/php.ini or /etc/php/8.2/fpm/php.ini depending on your stack), then reload: 
    sudo systemctl reload php8.2-fpm

Fix 3: .htaccess — only works with certain PHP handlers

You'll find this suggested everywhere, and it does work, but only if PHP is running as an Apache module (mod_php) or via suPHP with .htaccess overrides enabled:

php_value upload_max_filesize 256M
php_value post_max_size 300M
php_value memory_limit 512M

If your account runs PHP-FPM (the default on most modern cPanel servers), this will throw a 500 error instead of raising the limit — php_value lines in .htaccess aren't valid under FPM. If you add this and your site immediately breaks, that's your answer: remove it and use Fix 1 or Fix 2 instead.

WordPress-specific notes

A few things specific to WordPress that save time:

  • define('WP_MEMORY_LIMIT', '512M'); in wp-config.php only raises the memory ceiling WordPress requests — it cannot override upload_max_filesize or post_max_size. Server-level PHP settings always win.
  • Check Media > Add New — WordPress displays "Maximum upload file size: X MB" pulled straight from your live PHP config. If that number hasn't changed after you edit MultiPHP INI Editor, the change didn't take — check you edited the right domain, especially on addon domain setups where each domain can have its own PHP handler.
  • For WooCommerce CSV imports or large XML imports (All-in-One WP Migration, WP All Import), also check max_execution_time — big imports fail on timeout long before they fail on size.
  • Some security plugins (Wordfence, iThemes Security) impose their own upload restrictions independent of PHP. If PHP's limit is confirmed high but uploads still fail, temporarily disable the security plugin to isolate the cause.

Prevention

  • Set realistic limits for your actual use case — a 500-product WooCommerce catalog needs different PHP limits than a five-page brochure site.
  • Document what you changed and where (MultiPHP INI Editor vs .user.ini vs php.ini) so the next person troubleshooting doesn't fight three different override layers.
  • For very large one-off transfers (a 2GB database dump, a media library migration), skip the browser upload path entirely — use SSH/SFTP or the cPanel File Manager's direct upload, which isn't bound by the same POST-based PHP limits in most configurations.
  • On a VPS, keep memory_limit proportional to available RAM — several concurrent large uploads at 512M each can exhaust a small VPS fast. Watch this with free -h during testing.

Frequently Asked Questions

Why did raising upload_max_filesize alone not fix it?

Because post_max_size caps the entire request, not just the file. If it's still lower than your new upload_max_filesize, the request gets rejected before PHP even looks at the individual file size limit. Always raise both together, with post_max_size set higher.

I edited .htaccess and now my whole site returns a 500 error. What happened?

Your account is running PHP-FPM, which doesn't support php_value directives in .htaccess for these settings. Remove the lines you added and use MultiPHP INI Editor in cPanel instead — it's the equivalent fix that actually works under FPM.

How do I know which PHP handler my account uses?

Create a file called info.php with <?php phpinfo(); ?>, load it in a browser, and check the "Server API" line. It'll say something like FPM/FastCGI, CGI/FastCGI, or Apache 2.0 Handler. Delete the file afterward — phpinfo() output shouldn't stay publicly accessible.

Can I set unlimited upload size?

Technically yes with a large enough number, but it's a bad idea on shared or reseller hosting — CloudLinux LVE resource limits will kill a runaway upload process regardless of what php.ini says, and you'll just trade one error for a 508 Resource Limit error instead. Set a limit that matches real usage, then revisit it if requirements change.

Does changing PHP version reset these settings?

Yes. MultiPHP INI Editor settings are stored per PHP version per domain in most cPanel setups. If you switch a domain from PHP 8.1 to PHP 8.3 via MultiPHP Manager, check MultiPHP INI Editor again afterward — your custom upload limits may have reverted to that version's defaults.