How to Fix the upload_max_filesize Error of a Server for a WordPress Site

WordPress can reject a theme, plugin, or media upload because it exceeds a PHP or web-server limit. The important setting is upload_max_filesize, but it is not the only limit in the request path. Increasing one value without checking the others can leave the same error in place.

This guide concerns a self-hosted WordPress.org site. WordPress.com-hosted plans have different controls and may require a plan change or support request.

Check the current limits first

In WordPress, open Tools → Site Health → Info and inspect the server and PHP sections. The Media Library's upload screen also displays the maximum upload size on many versions. Record these PHP values:

upload_max_filesize = 256M
post_max_size = 256M
memory_limit = 512M
max_execution_time = 180

upload_max_filesize limits an individual uploaded file. post_max_size limits the entire POST request, so it must be at least as large as the file limit and should leave room for form fields. memory_limit controls PHP memory, not upload size directly, and max_execution_time controls processing time rather than network speed.

Do not copy large values blindly. Choose limits that match the files you genuinely expect, and remember that large uploads consume disk, bandwidth, backup space, and processing time.

Method 1: Use the hosting control panel

On cPanel and similar shared hosting, look for Select PHP Version, MultiPHP INI Editor, or a PHP options screen. Select the domain and the PHP version actually serving it, then update upload_max_filesize and post_max_size.

This is usually safer than editing .htaccess because the panel writes configuration in the format supported by the host. Save the changes and retest after a minute. If the panel offers no override, the host may enforce an account-wide ceiling.

Method 2: Edit the correct php.ini or PHP-FPM configuration

On a VPS, find the active PHP version and server API instead of editing every php.ini on the machine:

php -v
php -i | grep -E 'Loaded Configuration File|Server API'

Common FPM paths include /etc/php/8.3/fpm/php.ini on Debian/Ubuntu; replace 8.3 with the version used by the website. CLI PHP and web PHP can load different files, so confirm the web configuration through Site Health or your PHP-FPM pool configuration.

After editing, restart the correct service:

sudo systemctl restart php8.3-fpm

Use the actual unit name shown by systemctl list-units 'php*fpm*'. Restarting Apache or Nginx alone does not necessarily reload PHP-FPM settings.

For per-directory FPM or CGI setups, a .user.ini file in the WordPress root may be supported:

upload_max_filesize = 256M
post_max_size = 256M
memory_limit = 512M

Whether this works depends on the host and PHP handler. Changes to .user.ini can take a short cache interval to apply.

Method 3: Use .htaccess only with Apache and compatible PHP

The traditional approach adds these lines to WordPress's .htaccess file:

php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value memory_limit 512M
php_value max_execution_time 180

This works only when Apache allows the directives and PHP runs in a compatible mode, typically mod_php. It does not configure Nginx, and with PHP-FPM it may be ignored or cause an HTTP 500 error. Back up .htaccess before editing, and remove the directives immediately if the site starts failing.

Do not place random php_value lines in wp-config.php. Likewise, the old suggestion @ini_set('upload_max_size', '256M'); contains a misspelled setting and is not a reliable fix. Upload limits are generally established before WordPress runs, so application-level runtime changes often cannot raise them.

Method 4: Raise the Nginx request-body limit

If Nginx returns 413 Request Entity Too Large, the request may be rejected before PHP or WordPress sees it. Set client_max_body_size in the appropriate http, server, or location block:

client_max_body_size 256m;

A more specific block overrides an inherited value for that scope. Validate and reload Nginx after the change:

sudo nginx -t && sudo systemctl reload nginx

Nginx and PHP limits must both permit the upload. Apache can also have request limits, and a reverse proxy, CDN, or security appliance in front of the site can impose another one.

Method 5: Contact the host with useful details

Shared-hosting support may need to raise the limit for you. Tell them the domain, PHP version, current and desired upload_max_filesize and post_max_size, the exact error, and whether Nginx or another proxy returns a 413. This is more actionable than simply saying “WordPress is broken.”

If the host prohibits higher limits, use its supported large-file workflow or object-storage integration rather than trying to bypass account restrictions.

Troubleshooting checklist

• The setting changed but nothing happened: verify the PHP version serving the site, restart the correct FPM service, and check for a higher-priority pool or host setting.
• The site returns 500 after editing .htaccess: restore the backup and use the control panel or FPM configuration instead.
• The error is 413: inspect Nginx, proxy, and CDN body-size limits in addition to PHP.
• Small files work but large ones time out: check proxy timeouts, available disk space, network stability, and PHP-FPM logs. Raising max_execution_time alone may not address the bottleneck.
• The upload reaches WordPress but processing fails: check the uploads-directory permissions, disk quota, image-processing memory, and WordPress debug logs.

After the change, upload a test file near the intended size, confirm it appears correctly in Media Library, and remove the test if it is not needed. Keep the new limits no larger than your workload and storage policy require.