WordPress File Upload Limit: How to Actually Raise It
<p>WordPress shows the upload limit but the real value is set on your server. Three methods that work, plus the timeout and CDN ceilings most guides miss.</p>
WordPress shows “the uploaded file exceeds the upload_max_filesize directive” and the limit is almost always set on the server, not WordPress itself. For builders running production WordPress, here is the only fix order that actually works.
- Fastest fix: ask your host to raise the PHP
upload_max_filesizeandpost_max_sizevalues. On managed hosting this is a support ticket, not a code change. - If you have shell access: edit
php.inior drop a.user.iniin the WordPress root with the new values, then restart PHP-FPM. - If you have
.htaccesscontrol on Apache: addphp_valuedirectives. This will not work on Nginx or LiteSpeed without their own config syntax. - Skip: plugins that “increase” the upload limit by writing PHP constants. They paper over the actual server config and break in opaque ways on the next host migration.
- The real ceiling for production sites is the web-server timeout, not the PHP value. A 256MB upload behind a 30-second Nginx
client_body_timeoutwill still fail.
The error is misleading. WordPress reports the upload limit as if WordPress sets it, when in fact WordPress is reading the value back from PHP, and PHP is reading it back from the server config it inherits from your host. Three layers of indirection on a single number. We watch teams spend hours editing wp-config.php looking for a constant that does not exist before someone with hosting access changes it in a single field.
01Where the WordPress upload limit actually lives
The upload limit is the smallest of three PHP values: upload_max_filesize, post_max_size, and memory_limit. WordPress shows the smallest one as “Maximum upload file size” on the Media → Add New screen. The official PHP manual documents all three values and their interaction. The default values vary by host. WordPress’s own documentation on wp-config.php notes that the WordPress codebase itself does not set these limits.
| Setting | What it controls | Common default | Recommended for production |
|---|---|---|---|
upload_max_filesize | Maximum size of a single uploaded file | 2M to 64M | 128M to 256M |
post_max_size | Maximum size of an entire POST body (must be ≥ upload_max_filesize) | 8M to 64M | 256M (slightly above upload limit) |
memory_limit | How much memory PHP can allocate per request | 128M to 256M | 512M for media-heavy sites |
max_execution_time | How long PHP will run before killing the request | 30s | 300s for large media uploads |
The check on the host you are on is one line. Open Tools → Site Health → Info in WordPress admin, scroll to “Server”, and read the values. Or drop a one-line phpinfo(); file in your WordPress root and load it once. The numbers there are the truth. Anything else is a guess.
02Method 1: Ask your host (works on managed hosting)
If you are on Kinsta, WP Engine, Cloudways, SiteGround, Pressable, or any other managed WordPress host, this is the only correct method.
Buy if: your host has a support chat or a control-panel field for PHP limits. Skip if: you are on a self-managed VPS where you are the sysadmin.
Most managed hosts give you a control-panel slider or a chat ticket that flips both upload_max_filesize and post_max_size together. This is the safest path because the host sets the value at the layer they actually own, and the change survives PHP version bumps and server migrations.
- Kinsta: support ticket. They typically set
upload_max_filesizeandpost_max_sizeto 256M on request. - WP Engine: support chat. They cap at 50MB on lower plans and require an upgrade for higher.
- Cloudways: Server Management → Settings & Packages → Basic, edit the values, click save.
- SiteGround: Site Tools → Devs → PHP Manager → PHP Variables.
- Bluehost / HostGator / shared cPanel hosts: cPanel → Software → MultiPHP INI Editor.
upload_max_filesize and post_max_size to 256M, and max_execution_time to 300 seconds, on the PHP pool serving [domain].” Most tickets close in under an hour.
03Method 2: Edit php.ini or drop a.user.ini (shell or sFTP access)
The right method on a self-managed VPS or any host that runs PHP-FPM and respects per-directory .user.ini files.
Buy if: you have shell or sFTP access and your host runs PHP-FPM. Skip if: the host caps values from above (most shared hosts do).
Create a file called .user.ini in your WordPress root (the directory with wp-config.php) with the values you want. PHP-FPM will pick the file up automatically. The change applies to that directory and below, which means only the WordPress install, not the whole server.
- 1Connect via sFTP or SSH to the WordPress root
- 2Create or open
.user.ini - 3Add the directives, save the file
- 4Wait 5 minutes for PHP-FPM cache, or restart PHP-FPM
- 5Verify in WordPress admin → Tools → Site Health → Info
The contents of .user.ini are the same four lines you would putphp.ini:
upload_max_filesize = 256M
post_max_size = 256M
memory_limit = 512M
max_execution_time = 300The user_ini.cache_ttl directive in PHP defaults to 300 seconds. That is why the change does not appear immediately. Either wait or restart PHP-FPM with sudo systemctl restart php8.3-fpm (or whichever PHP version your host runs). On root-level php.ini the file is at /etc/php/8.3/fpm/php.ini on Debian/Ubuntu and /etc/php.ini on most RHEL-family distros, but only edit it if you own the server.
04Method 3: Edit.htaccess (Apache only)
Works on classic Apache + mod_php setups, which are an ever-shrinking minority. Has no effect on Nginx, LiteSpeed, or PHP-FPM-only Apache.
Buy if: your host explicitly runs Apache with mod_php and you have AllowOverride All. Skip if: you do not know what your web server is.
Add the lines below to .htaccess in the WordPress root. Apache picks them up on the next request. The directive only works on Apache running PHP as a module. Most modern hosts run PHP-FPM, where the php_value syntax is silently ignored.
php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value memory_limit 512M
php_value max_execution_time 300.htaccess takes the entire site down with a 500 error. Test the change on a staging copy first. If you are on Nginx or LiteSpeed and the directives have no effect, do not pile on more lines. The syntax does not apply.
05The web-server timeout is the next limit you will hit
Once PHP accepts a 256MB body, the next ceiling is the web-server’s body-read timeout. Nginx defaults client_body_timeout to 60 seconds. A user on a 5 Mbps upload will not finish a 256MB file in 60 seconds. The upload will fail at the proxy layer with a 408 or a connection reset, before PHP even sees the request.
For Nginx in front of WordPress, the values to raise are client_max_body_size 256M, client_body_timeout 300s, and send_timeout 300s. Set these in the server block, not the http block, so they apply per site. On Cloudflare in front of the origin, free and Pro plans cap upload size at 100MB; Business plans cap at 200MB; Enterprise lifts it to 500MB. Files above the Cloudflare cap need to bypass the proxy or use a presigned upload to direct storage. If your CDN is the limit, no amount of php.ini edits will help.
06Which method should you pick?
Pick the right approach
- Managed WordPress host? → Method 1 (ask the host)
- Self-managed VPS with PHP-FPM? → Method 2 (.user.ini or php.ini)
- Apache with mod_php and AllowOverride All? → Method 3 (.htaccess)
- Site behind Cloudflare with files above 100MB? → Bypass the proxy or move uploads to S3-compatible storage
- Still failing after all of the above? → It is the web-server timeout, not the PHP limit. Raise
client_body_timeout.
07Why we do not recommend the “increase upload limit” plugins
A handful of plugins claim to raise the WordPress upload limit. What they actually do is define PHP constantswp-config.php like WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT. These touch the WordPress-side memory ceiling, not the PHP upload_max_filesize value. They cannot raise a server-imposed limit. They appear to work in some environments because the server limit was already high enough.
The cost of using one is opacity. When the next host has a different default, the plugin’s claims do not match reality, and the team spends an afternoon debugging an “increased” limit that is still 32MB. Edit the actual layer instead.
08FAQ
Why does my site say “the uploaded file exceeds the upload_max_filesize directive in php.ini”?
PHP’s upload_max_filesize setting is below the size of the file you tried to upload. The setting livesphp.ini on the server. Either raise it via your host’s control panel or edit php.ini directly if you have shell access. The setting is not in WordPress itself.
What size should I set upload_max_filesize to for production WordPress?
256MB is the right ceiling for media-heavy sites. It covers most podcast episodes, video segments, and design files without exposing the server to abuse. Make sure post_max_size equals or exceeds it.
Does wp-config.php control the upload limit?
No. wp-config.php can raise WP_MEMORY_LIMIT for WordPress’s PHP memory budget, but it does not change the PHP upload_max_filesize setting. That value is read from php.ini or a .user.ini file by the PHP runtime before WordPress even loads.
Will Cloudflare block large uploads even if my server allows them?
Yes. Cloudflare’s free and Pro plans cap upload size at 100MB. Larger files need to bypass the proxy (set the DNS record to “DNS only”) or use a direct-to-storage upload pattern with a presigned URL.
Why does the change to .user.ini not show up immediately?
PHP-FPM caches .user.ini reads for 300 seconds by default. Wait five minutes, or restart PHP-FPM with sudo systemctl restart php8.3-fpm to apply the change immediately.
09WikiWalls verdict
WikiWalls verdict. If you pay for managed hosting, ask the host. If you run your own server, edit
.user.ini. Skip the plugins. Once PHP accepts the file, check your web-server timeout and your CDN cap before assuming WordPress is the problem.
This guide was last reviewed and updated by WikiWalls recently to reflect current PHP-FPM defaults, Cloudflare upload caps, and managed-hosting control-panel layouts.
