How to increase the maximum upload file size in WordPress

WordPress caps how big a file you can upload through the admin dashboard. The default on most hosts is somewhere between 2 MB and 64 MB, which is fine for images and small PDFs but falls over the moment you try to upload a video, a design mockup, a plugin ZIP, or a database export. The error message is clear enough – “exceeds the maximum upload size for this site” – but the fix is not quite as obvious as it looks, because four different settings across two or three different layers all have to line up before the upload goes through.

This guide covers what the current limit actually is, the four values you need to change to increase it, where to change them based on what kind of hosting you have, and how to handle the cases where “just raise the limit” is not the right answer (for uploads larger than about 500 MB, it usually is not).

Check the current limit first#

Before changing anything, confirm what the limit is right now. In the WordPress admin:

1. Go to Media > Add New
2. The uploader box shows “Maximum upload file size: X MB” below the drop zone

That number is the smaller of upload_max_filesize (PHP’s setting) and any other layer in front of PHP (the web server’s body size limit, proxy timeouts, etc.). WordPress reports the lowest ceiling it can see, which is usually PHP’s.

If you need to see every relevant value at once, go to Tools > Site Health > Info > Server – the Upload max filesize and PHP post max size entries show PHP’s limits directly.

The four settings that all need to match#

This is the part most tutorials skip and that causes most of the “I raised the limit but it still does not work” complaints. There are four PHP settings involved in an upload, and if any one of them is lower than the file size, the upload fails. They are:

Additionally, on the web server layer, client_max_body_size in nginx (or LimitRequestBody in Apache) has to be at least as large as post_max_size , or the request fails with a 413 Request Entity Too Large before PHP ever sees it.

Why post_max_size has to be bigger than upload_max_filesize

The entire POST request includes the file plus any form fields (post title, metadata, CSRF token, other attached files in multi-upload). If post_max_size is set equal to upload_max_filesize , a file right at the limit plus even a few bytes of form data exceeds the POST size, and PHP silently discards the body. WordPress sees an empty upload with no useful error. Always set post_max_size to at least double.

Why the timeouts matter for large uploads

A 500 MB file uploaded over a 10 Mbps home connection takes roughly seven minutes of continuous transfer. If max_execution_time is 60 seconds, PHP kills the process at the one-minute mark and the upload fails partway through. The temporary file gets cleaned up, so you do not even have a partial file to recover.

The full short-list of PHP directives that matter for WordPress (these four plus memory_limit and max_input_vars ) is in WordPress hosting requirements – the hub page that cross-links every PHP setting to its own troubleshooting guide.

Where to change these values#

The right place depends on how your hosting is set up. Start with option 1 and work down – the lower-level methods exist as fallbacks, not as the preferred approach.

Option 1: Hosting control panel (easiest, works on most modern hosts)

Every serious hosting provider in 2026 exposes PHP settings through the control panel without requiring SSH or config file edits. Look for a section called PHP Manager, PHP Settings, PHP Configuration, or similar. Inside it, you should see editable values for at least these directives:

• upload_max_filesize
• post_max_size
• max_execution_time
• max_input_time

Change the values, save, and the updated settings apply to your site. Most panels apply the change within seconds (no server reload required on your end). Reload the WordPress Media Library page and confirm the new maximum shows up.

On Hostney specifically: Go to Hosting > PHP Manager, select the site, open the Variables tab, and edit each directive. Changes apply immediately to the site’s PHP container. A full 40 PHP directives are configurable per site this way – the four upload-related ones, plus OPcache settings, session handling, error logging, and others. The one PHP setting that is NOT exposed here is memory_limit , which is managed at the platform level per plan and not user-editable (raising memory_limit is usually the wrong fix for whatever you are trying to solve anyway).

Option 2: .user.ini in the WordPress root (for PHP-FPM hosts without a PHP UI)

Many shared hosts run PHP as PHP-FPM and support per-directory .user.ini files. Create a file called .user.ini in your WordPress root (the directory containing wp-config.php ) with the values you need:

upload_max_filesize = 256M
post_max_size = 512M
max_execution_time = 600
max_input_time = 600

PHP re-reads .user.ini on a configurable interval (default 5 minutes). To force an immediate reload on most setups, restart PHP-FPM – or wait five minutes and check Media > Add New.

.user.ini is the most portable fallback. It works on nginx, Apache, cPanel, Plesk, and most shared-hosting control panels without requiring root access. It does not work on mod_php Apache setups – those use .htaccess .

Option 3: php.ini (VPS, dedicated servers, or hosts that give you a per-site php.ini)

If you control the server or your host gives you a dedicated php.ini , edit it directly:

upload_max_filesize = 256M
post_max_size = 512M
max_execution_time = 600
max_input_time = 600

Restart PHP-FPM ( systemctl restart php8.3-fpm or similar, matching your PHP version) or whatever PHP process is serving WordPress. The change takes effect after the restart.

Some hosts split the php.ini into per-directive snippets under a conf.d directory. If that is the case, either edit the existing snippet or create a new file like /etc/php/8.3/fpm/conf.d/99-custom.ini with your overrides. The numeric prefix controls load order – higher numbers override lower ones.

Option 4: .htaccess (Apache with mod_php only)

On Apache servers using mod_php (not PHP-FPM), you can set PHP values in .htaccess :

php_value upload_max_filesize 256M
php_value post_max_size 512M
php_value max_execution_time 600
php_value max_input_time 600

This does NOT work on nginx, does NOT work on Apache with PHP-FPM, and does NOT work on most modern managed hosts. If you edit .htaccess and nothing changes, your host is almost certainly not running mod_php. Use option 2 (.user.ini) instead.

Option 5: wp-config.php (limited – only some directives work)

Some PHP directives can be set via @ini_set() calls in wp-config.php :

@ini_set('upload_max_filesize', '256M');
@ini_set('post_max_size', '512M');
@ini_set('max_execution_time', '600');

The catch: upload_max_filesize cannot be changed at runtime on most PHP configurations. It has to be set in php.ini or .user.ini before PHP starts processing the request. The ini_set call silently fails and the value stays at whatever the server-level config says. max_execution_time works fine this way; upload_max_filesize and post_max_size usually do not.

Use this option only as a last resort and verify the change actually took effect via Site Health.

Why the change might not take effect#

If you edited the right file and the WordPress Media Library still shows the old limit, work through these in order:

1. You edited a php.ini that PHP does not actually load. A server can have multiple php.ini files (one for CLI, one for FPM, one per-version if you have PHP version switching). Confirm which file is loaded at runtime: Tools > Site Health > Info > Server shows the loaded php.ini path. Edit that one.

1. OPcache cached the old config. PHP’s OPcache caches parsed configuration alongside compiled code. After changing PHP settings, either restart PHP-FPM or clear OPcache. On most hosts the control panel has a “restart PHP” or “clear OPcache” button; otherwise systemctl restart php8.3-fpm restarts the whole thing.

1. You edited the PHP version that is not currently active. On hosts with multiple PHP versions (very common), changing php.ini for PHP 8.1 does nothing if the site is running PHP 8.3. Check the active version in Site Health and edit the matching config.

1. The nginx/Apache limit is lower than your new PHP limit. PHP raising its cap to 256M does not help if nginx still rejects anything over 64M with a 413. The 413 guide covers client_max_body_size and how to align the web server with PHP.

1. A plugin overrides the value. Some security or performance plugins set their own upload limits. Deactivate plugins one at a time (or check the plugin’s settings page) to find the culprit.

1. Browser cached the old Media Library page. Rare but worth ruling out. Hard-refresh the upload page (Ctrl+Shift+R or Cmd+Shift+R).

When raising the limit is the wrong fix#

Above roughly 500 MB, the standard POST upload pipeline starts falling apart regardless of what PHP says is allowed. The upload takes long enough that network hiccups, timeouts in front of PHP (load balancer, CDN, reverse proxy), and browser-side memory issues become more common than they are for smaller files. At that scale, the right answer is not to keep raising the cap – it is to use a different transfer method.

Chunked upload plugins

Plugins like Big File Uploads, Infinite Uploads, or Chunked Upload break a large file into smaller pieces client-side, upload them one at a time, and reassemble server-side. Each individual HTTP request stays under the PHP limit, and the plugin handles the orchestration. This works within WordPress’s normal upload flow without raising any server limits – just install the plugin, configure the chunk size, and uploads start working for files well into the gigabyte range.

SFTP or SSH for one-off files

If you need to upload one large file (a database export, a video master, a plugin package from a developer) and you are not going to do it regularly, SFTP is more reliable than any WordPress-level upload method. Connect with an SFTP client, put the file in /wp-content/uploads/YYYY/MM/ manually, and WordPress picks it up in the Media Library once a plugin like “Add From Server” scans for unregistered files. Or just reference the file directly in theme templates without registering it in the Media Library at all.

Direct-to-cloud uploads

For very large files (5 GB+), even SFTP gets painful. The right pattern is to upload directly from the browser to a cloud storage bucket (S3, R2, Backblaze B2) using pre-signed URLs, then reference the cloud URL from WordPress rather than hosting the file on your own server. Plugins like WP Offload Media automate this for WooCommerce products, membership site downloads, and similar use cases.

Common mistakes#

• Setting upload_max_filesize higher than post_max_size . PHP silently discards the POST body and the upload fails with no useful error. Always set post_max_size to at least 2x the upload file size.
• Forgetting to raise max_execution_time along with the upload size. The upload succeeds at receiving data but PHP kills the process before the file is moved to final storage. The file appears in /tmp briefly, then gets cleaned up.
• Editing .htaccess on an nginx or PHP-FPM server. .htaccess does nothing on either; the edit has no effect. Use the control panel or .user.ini instead.
• Raising the PHP limit but not the nginx client_max_body_size . nginx blocks the request before PHP sees it. You get a 413 instead of the expected PHP error. Both layers have to be raised together.
• Treating “it worked locally” as proof. Your local PHP setup (XAMPP, Local by Flywheel, DDEV, Docker) has completely different limits than production. Test uploads against the actual production environment before assuming a workflow works.
• Raising limits to gigabytes “just in case.” High PHP limits leave a larger surface for abuse – someone uploading a stack of 500 MB files can exhaust disk space or PHP worker slots. Match the limit to the actual largest file you need to upload, not a theoretical maximum.
• Relying on @ini_set() in wp-config.php for upload_max_filesize . It does not work for that directive in most PHP configurations. Silent failure. Use php.ini, .user.ini, or the control panel.

How Hostney handles upload size#

Hostney exposes the four upload-related directives ( upload_max_filesize , post_max_size , max_execution_time , max_input_time ) through Hosting > PHP Manager > Variables as editable per site. Changes apply immediately to the site’s PHP container – no wait for propagation, no support ticket, no server restart on your end. The defaults are set conservatively (64 MB for upload_max_filesize and post_max_size , 120 seconds for max_execution_time ) to keep accounts from getting into trouble with defaults that are too permissive, but any site that genuinely needs higher limits can raise them to the plan ceiling.

The nginx layer ( client_max_body_size ) is kept in sync with the PHP-level post_max_size automatically, so you only have to adjust one side – the “nginx limit is lower than the PHP limit” class of 413 errors does not apply.

For very large uploads (hundreds of MB or gigabyte-range), the chunked-upload plugins mentioned above are still the better approach – they work on Hostney exactly as described, and sidestep the reliability issues of transferring a gigabyte in a single HTTP POST. SFTP access is also available per account for cases where direct file placement is simpler than plugin orchestration.

memory_limit is the one PHP directive NOT exposed in PHP Manager. It is set at the plan level per container (512 MB for most plans, 768 MB on specific configurations). Upload size is not a memory_limit question in practice – PHP streams uploaded files through memory rather than loading them whole – so this rarely matters for upload configuration.

Summary#

The WordPress upload size cap comes from four PHP directives ( upload_max_filesize , post_max_size , max_execution_time , max_input_time ) plus the web server’s own body-size limit. Raise all of them together, keep post_max_size at least double upload_max_filesize , and confirm the change took effect via Media > Add New or Tools > Site Health > Info > Server. The control panel is the right place to make the change on managed hosting; .user.ini is the right fallback on shared hosting; .htaccess is only for Apache mod_php and does nothing on modern PHP-FPM setups; wp-config.php @ini_set() calls only work for some directives and silently fail for upload_max_filesize . Above about 500 MB, stop raising limits and use a chunked-upload plugin, SFTP, or direct-to-cloud uploads instead – the standard POST pipeline is not the right tool at that scale.