Why WordPress will not let you upload your video, and the four ways around it

Raising the WordPress upload limit is usually a two line change. You open php.ini, set upload_max_filesize to something larger, set post_max_size above it, restart PHP, and the Media screen prints the new number. On a server you control, that is the entire fix, and it holds for as long as your files stay roughly the size they are now.

It stops being the entire fix when the number on the Media screen goes up and the upload still dies. That number reads two PHP directives and nothing else. It cannot see nginx, where client_max_body_size defaults to one megabyte and returns a 413 before PHP is handed the body. The rejection sits in the nginx error log and never reaches wp-admin.

Four separate ceilings can stop a 900 MB lecture recording, and from inside WordPress the failure looks identical whichever one you hit. This tutorial covers how to read the effective limit, how to tell the four apart from the symptom, and the four fixes in order of how long each one lasts.

TL;DR

The Media screen prints the smaller of upload_max_filesize and post_max_size, and nothing else. post_max_size has to sit above upload_max_filesize, or PHP discards the request whole. memory_limit is on every checklist and is the least likely of the four to be your problem with video. The fourth ceiling belongs to your host, usually nginx or a proxy, and no PHP edit reaches it. Editing ini files, asking the host and compressing the file all buy time. Chunked resumable upload removes the ceiling.

Read the effective limit before you change anything

Open Media, then Add New Media File. WordPress prints Maximum upload file size under the drop zone. That figure comes from wp_max_upload_size(), which takes the smaller of upload_max_filesize and post_max_size, then passes it through the upload_size_limit filter. A plugin or a host mu-plugin can lower it further.

Now open Tools, Site Health, Info. The Media Handling panel lists the uploaded file size, the post data size and the effective size as separate rows. The Server panel repeats the directives beside the memory and time limits. Compare those against the php.ini you edited. If they disagree, another file is winning: a .user.ini, a host override, or a php.ini from a different PHP install.

The four ceilings, and which one stopped your upload

Each ceiling fails in its own way, and the symptom is how you tell them apart.

memory_limit needs a note, because it is on every checklist and is the least likely of the four to be stopping a video. PHP writes an upload to a temporary file on disk and WordPress moves it, so the video never has to fit in memory. Memory bites on images, where GD or Imagick decompresses the file into a bitmap to build each sub-size.

Why post_max_size has to be the larger number

post_max_size caps the whole request body. That body carries the file, the form fields, the security nonce and the multipart boundaries, so it is always bigger than the file alone. Set the two directives to the same value and a file at exactly the limit still fails.

The failure is quiet. When the body exceeds post_max_size, PHP drops it and populates neither $_POST nor $_FILES. The nonce vanishes with the file, so WordPress cannot tell you which directive was hit. Give post_max_size clear headroom and the error text starts naming the real cause.

Fix 1: raise the PHP limits yourself

This is the right first move when you control the server. Set both directives in php.ini, in a .user.ini when PHP runs under FPM or CGI, or with php_value in .htaccess under mod_php. Restart PHP-FPM afterwards, because a web server reload alone will not pick the change up.

One thing to skip: both directives are PHP_INI_PERDIR, and PHP applies them while parsing the request. Your code has not run yet. An ini_set() call in wp-config.php or a snippet plugin cannot move either one, which is why that advice keeps failing.

While you are in there, check max_input_time. A 900 MB upload over a home connection can outlast the default window, and a timeout mid-transfer looks exactly like a size rejection.

Fix 2: ask the host, and what to ask for

On managed hosting you cannot edit any of this, so the request is the fix. Vague requests get vague answers. Name the directives and the values you want, and ask whether the cap also exists at the proxy layer.

Ask for three things in the ticket:

1. upload_max_filesize and post_max_size raised to named values, with post_max_size the larger of the two.
2. Confirmation of client_max_body_size, or the equivalent body limit on whatever sits in front of PHP.
3. The plan's hard cap, if there is one, in writing.

Plenty of platforms hold a fixed limit for every site on the plan, and a CDN in front can hold another. Cloudflare's lower plans cap the request body at 100 MB, whatever your origin allows. When the answer is a number the host will not move, the first two fixes are finished.

Fix 3: compress or split the file, and what it costs

Compression works, and it has the worst exchange rate of the four. Squeeze a one hour recording into 64 MB and you are budgeting roughly 0.15 Mbps for picture and sound together. Slide text stops being legible. Trimming a file by a third is reasonable. Clearing an order of magnitude is not, and video encoding vs transcoding covers what each pass does to the source.

Two details save time. Zipping an MP4 gains almost nothing, because the video is already compressed. And splitting a recording leaves several attachments and several players in the post, with no way to stitch them into one timeline.

This is also where the ceiling starts shaping the content. Once you are cutting a lecture in half to get it through a form, the limit is deciding what you publish.

Fix 4: keep the bytes out of WordPress

The first three fixes accept the same premise, that your video reaches your server inside one HTTP POST. Drop that premise and every ceiling above goes with it, because no single large request is left for anything to reject.

The FastPix WordPress plugin works this way. Its Add media screen cuts the file into 5 MB chunks in the browser and sends them straight to the platform, so nothing large crosses your PHP configuration. WordPress stores a record of the video, not the video. The mechanics are in how to upload large video files efficiently using chunking.

Resumability is what matters on a bad connection. An upload that fails at 68 percent through a single POST starts again from zero. FastPix retries the failed chunk on its own, and you can leave the page once the upload has started. A closed browser leaves a Resume upload action that asks for the same file and carries on. Several files can go at once. Pause and resume uploads covers the model.

If the file already sits somewhere reachable, skip the browser. Paste a public URL into the same screen and FastPix fetches it directly, which beats downloading a 900 MB archive copy only to upload it again.

Be clear about the price. You are adding a dependency and a second system, with its own account, its own bill and its own failure modes. There is still a ceiling, just a different one: a single upload can run up to 8 hours. The file also leaves wp-content, which changes your backups and what you hold if you leave. Moving a WordPress Media Library off your server works through that trade.

How long each fix lasts

The first three buy time, in different amounts. The fourth changes what the upload form does, which is why it is the only row without a size in the middle column. That is no reason to reach for it first. If you run your own server and your files are 200 MB, fix one is finished in ten minutes.

Upload your largest file without editing php.ini

The quickest way to find out which ceiling you are on is to send one file past all of them. Install the FastPix WordPress plugin, connect a workspace, and drop your largest recording onto the Add media screen. The browser chunks it and you can close the tab. The file that failed at 68 percent through wp-admin lands without a PHP change. The free plan covers 10 videos, no card required.