"File Exceeds the Maximum Upload Size for This Site"

Why it happens

• The file is bigger than the limit WordPress printed under the upload box (Media → Add New → Maximum upload file size). That limit is the smaller of PHP's upload_max_filesize and post_max_size. The file never leaves your browser.
• Only one of the two PHP settings was raised. The other one still sets the limit, so the number on the page does not move.
• The new value was put somewhere your server ignores: a .user.ini file on Apache with PHP as a module, or ini_set() in wp-config.php. Neither can change these two settings there.
• The host sets the limit for the whole account, and a file or setting you control cannot go above it.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

WordPress reads two PHP settings, upload_max_filesize and post_max_size, and takes the smaller. It prints that number under the upload box. When you pick a bigger file, your browser stops the upload and shows this message. Nothing is sent to the server. To clear it, raise both settings and reload the page.

What you see#

On Media → Add New, a red row appears under the upload box with the file name and the message. The line above it shows the limit.

The block editor uses a different sentence for the same check. When you add an image block and upload the same file, a small notice appears at the bottom:

I checked these two screens. WordPress 7.1.4 also has a third wording in its media script, a "File too large" notice that says "photo.jpg" exceeds the maximum upload size. I did not trigger it. It names the same limit, so the fix is the same. The Media Library pop-up and the classic uploader use the Media → Add New wording.

Both screens I tested show the message in the browser before any upload starts. I watched the network on both: no request to async-upload.php or the media API was sent.

How it works#

On each page that can upload, WordPress calls wp_max_upload_size() and hands the result to the browser. The function is short:

$u_bytes = wp_convert_hr_to_bytes(	ini_get( 'upload_max_filesize' ) );$p_bytes = wp_convert_hr_to_bytes(	ini_get( 'post_max_size' ) );return apply_filters( 'upload_size_limit',	min( $u_bytes, $p_bytes ), $u_bytes, $p_bytes );

The classic uploader gets it as a max_file_size filter and the block editor as the setting maxUploadFileSize. In the browser, a file larger than that number is refused on the spot with the strings above.

That is why raising one setting does nothing. In the table, "upload max" is upload_max_filesize and "post max" is post_max_size. I set each one alone with .htaccess on a test site:

The first two numbers are PHP's built-in defaults, 2M and 8M. Your host may have different ones.

Which setting methods work#

Here is what I measured on Apache with PHP as a module (php_sapi_name() returned apache2handler), the setup of many shared hosts. PHP's manual says both settings are INI_PERDIR, which means they can be set in php.ini, .htaccess or the server config, but not at run time.

On PHP-FPM, the table is different: .user.ini is the file PHP reads and .htaccess php_value lines are not. I did not test FPM, so follow the PHP manual and check the result on Media → Add New.

A bigger limit in a filter does not raise anything#

A common snippet returns a bigger number from the upload_size_limit filter. It changes what the page prints and what the browser allows. It does not change PHP. With the filter at 64 MB and PHP still at 2M and 8M, the browser sent the file and PHP refused it:

“photo.jpg” has failed to upload.The uploaded file exceeds the upload_max_filesize directive in php.ini.

So the filter can lower the limit, or make the page tell the truth when the server is already higher. It cannot lift a PHP limit. For that message, see the page for "The uploaded file exceeds the upload_max_filesize directive".

What each layer says#

Once the browser check passes, other layers can still stop the file. I forced each one with the filter set to 64 MB so the browser let the file through:

A row stuck at 100% is the sign. Open the browser's network panel, find the async-upload.php request and read its status. For a 413, ask your host to raise the web server limit. Do not trust a screen that only shows a progress bar.

Edge cases I checked#

• WP-CLI ignores the limit. wp media import took the 4.8 MB file with the limit at 2 MB.
• The REST API takes a raw body. A plain POST of the file to /wp/v2/media returned 201 with the limit at 2 MB, because PHP's two limits apply to form uploads. Do not rely on this to skip the limits for people. It is a quirk of how the request is read.
• Multisite has its own file size setting, Max upload file size under Network Admin → Settings → Network Settings. WordPress also applies it, so a network limit lower than PHP's gives the same message. I did not test it here. Ask the network admin to raise it.

After it is fixed#

Keep the limit only as high as the biggest file you really upload. A very high limit lets a stuck upload tie up the server for a long time. If the upload dies after a long wait, see maximum execution time exceeded. If the browser shows a web server page instead of this message, see 413 Request Entity Too Large. To read the numbers again at any time, use Tools → Site Health → Info → Media Handling. The guide to Site Health explains the rest of that screen.