The Uploaded File Exceeds the upload_max_filesize Directive: Fixing It in the Right Place

Q: Which php.ini file do I need to edit?

Run php --ini to see the loaded configuration file. Be aware the CLI and web server often use different files — check the Loaded Configuration File row in phpinfo() output for the web server's, then delete the phpinfo file immediately.

This error means your file is larger than PHP’s upload_max_filesize setting. The reason raising that one value so often fails to fix it is that four separate limits govern an upload, and the smallest one wins — silently, without telling you which one it was.

So the fix is not one number. It is making sure four numbers are consistent with each other, in a file that PHP is actually reading, on a server that has actually been restarted. Each of those three clauses is a place people get stuck.

The four limits that all have to agree
Finding the file PHP is actually reading
Restarting the right thing
When you cannot edit php.ini
The limits above PHP
The WordPress-specific parts
How this fits the rest of the stack
FAQ

The four limits that all have to agree

An upload passes through several ceilings on its way in. In the order they bite:

upload_max_filesize — the maximum size of a single uploaded file. The one named in the error.
post_max_size — the maximum size of the entire POST body, which includes the file plus every other form field. Must be larger than upload_max_filesize, because the request is bigger than the file it carries.
memory_limit — the maximum memory a PHP script may use. Should comfortably exceed post_max_size, particularly for image processing where the file is decompressed in memory.
max_execution_time and max_input_time — how long the script may run, and how long PHP may spend parsing the request. Large uploads on slow connections hit these before they hit any size limit.

The rule that makes this simple: memory_limit > post_max_size > upload_max_filesize. If you want to allow 64MB uploads, that is upload_max_filesize 64M, post_max_size 128M, memory_limit 256M.

The failure mode when post_max_size is too small is particularly nasty. PHP discards the entire request body, so $_POST and $_FILES both come back empty. Your code sees a form submission with no data and no error, which looks like a bug in your form rather than a configuration limit.

Finding the file PHP is actually reading

The most common reason an edit does nothing is that it was made to a php.ini that is not the one in use. There are usually several on a system.

Ask PHP directly rather than guessing:

php --ini

That prints the loaded configuration file and any additional .ini files scanned from a conf.d directory. Edit the one it names.

Careful: the CLI and the web server frequently use different php.ini files. A change that works from the command line and not in the browser means you edited the CLI one. To see what the web server is using, create a file containing a phpinfo() call, load it in a browser, and read the Loaded Configuration File row — then delete the file immediately, because phpinfo output is a detailed map of your server for anyone who finds it.

Verify the values took effect rather than assuming:

php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit'

Restarting the right thing

PHP reads its configuration at startup. Editing php.ini changes nothing until the process that reads it restarts, and which process that is depends on how PHP runs.

PHP-FPM — restart the FPM service, not the web server. Restarting nginx or Apache alone does nothing because FPM is a separate long-running process. This is the single most common reason a correct edit appears to have no effect.
mod_php — PHP runs inside Apache, so restarting Apache is correct.
CGI or FastCGI — usually picks up changes on the next request, but restarting is safer.

If you are not sure which you have, restart both. It costs a second of downtime and removes an entire category of confusion.

When you cannot edit php.ini

On shared hosting you often have no access to the real php.ini. Three fallbacks, in order of how well they work:

A .user.ini file in the directory, which works with PHP-FPM and CGI:

upload_max_filesize = 64M
post_max_size = 128M
memory_limit = 256M

Note that .user.ini is cached — by default for 300 seconds — so changes are not instant. Wait, or restart FPM if you can.

An .htaccess directive, which only works with mod_php:

php_value upload_max_filesize 64M
php_value post_max_size 128M

If PHP runs as FPM, these lines cause a 500 error rather than being ignored, so test carefully.

In application code, using ini_set. This works for memory_limit and max_execution_time but not for upload_max_filesize or post_max_size — those are read before your script runs, so setting them from PHP is too late by definition. This is worth knowing because a lot of advice on the internet suggests it and it cannot work.

The limits above PHP

If all four PHP values are correct, verified, and restarted, and uploads still fail, the limit is in front of PHP.

nginx has its own body size limit, defaulting to 1MB, and it rejects the request before PHP ever sees it. The symptom is a 413 Request Entity Too Large rather than the PHP error:

client_max_body_size 128M;

Apache has LimitRequestBody, though it defaults to unlimited so it is less often the culprit.

A CDN or reverse proxy in front of everything may have its own cap, often lower than you expect and frequently not configurable on lower plans. If uploads work when you hit the origin directly and fail through the CDN, that is your answer.

The ordering to remember: the request passes CDN, then web server, then PHP. Whichever limit it meets first is the one that rejects it, and each layer reports the failure differently.

The WordPress-specific parts

WordPress adds two things on top of the PHP limits.

The admin interface displays the effective maximum on the media upload screen. That number is WordPress reporting what PHP told it, so if it does not change after your edit, PHP has not picked up the change — the problem is upstream of WordPress entirely.

There is also WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT in wp-config.php, which set memory limits for the front end and admin respectively. These can only raise the limit within what PHP allows; they cannot exceed the php.ini memory_limit.

For genuinely large media, the more robust answer is not to raise the limit but to avoid the HTTP upload path — uploading via SFTP or a file manager and importing the media library entry sidesteps every limit above. A 500MB video is not something an HTTP form post handles gracefully at any configured limit.

How this fits the rest of the stack

Almost every version of this problem is really one problem: the limit that rejected the request is not the limit you changed, and nothing tells you which one it was. Being able to see the request in the runtime log next to the response the server sent removes most of the guessing. Managed WordPress on RunxBuild includes a dashboard file manager for uploads that should not go through a form post at all, and services expose their configuration as environment settings rather than files you have to locate on disk. When you are sizing storage and bandwidth alongside the app, the RunxBuild hosting calculator itemises them.

Useful related references:

FAQ

Why does raising upload_max_filesize not fix the error?

Because post_max_size is usually still lower. The POST body contains the file plus all other form fields, so post_max_size must be larger than upload_max_filesize. The smallest applicable limit always wins.

Which php.ini file do I need to edit?

Run php —ini to see the loaded configuration file. Be aware the CLI and web server often use different files — check the Loaded Configuration File row in phpinfo() output for the web server’s, then delete the phpinfo file immediately.

Why do my changes take no effect after editing php.ini?

Usually because PHP-FPM was not restarted. Restarting nginx or Apache does not reload FPM, which is a separate long-running process. Restart the FPM service specifically.

Can I set upload_max_filesize with ini_set in my code?

No. PHP reads upload_max_filesize and post_max_size before your script executes, so setting them at runtime is too late. Only memory_limit and max_execution_time can be usefully changed with ini_set.

What causes a 413 error instead of the PHP message?

A limit in front of PHP — most often nginx’s client_max_body_size, which defaults to 1MB and rejects the request before PHP sees it. A CDN or reverse proxy can also impose its own cap.