How to Increase the Maximum Upload File Size in WordPress

You drag a 60MB video into the WordPress media library, wait a few seconds, and get back one of three error messages: "The uploaded file exceeds the upload_max_filesize directive in php.ini", "413 Request Entity Too Large", or simply "HTTP error" with no further explanation. The fix is almost always to raise the maximum upload size, but as with most WordPress limit topics, there is not just one limit. There are four, they live in different places, and the lowest one wins. This guide walks through which limit causes which error message, and how to raise each of them on the various host setups.

Which limit is responsible for which error?

Four separate settings can block an upload. Knowing which one bit you saves a lot of trial and error.

PHP upload_max_filesize. The hard ceiling on the size of a single uploaded file. Default on most hosts is 2M to 64M. If your file exceeds this, WordPress shows the explicit "uploaded file exceeds the upload_max_filesize directive" message.
PHP post_max_size. The maximum size of the entire POST request, including the file plus any other form fields. Has to be at least as large as upload_max_filesize; otherwise the upload silently fails before WordPress even sees it. Default is typically 8M to 64M.
PHP max_execution_time and max_input_time. Time limits in seconds. A large upload over a slow connection can hit the time limit before the file finishes transferring, even if the size limits are fine. Default is usually 30 to 60 seconds. Symptom: upload starts, progress bar gets to 80%, then fails with "HTTP error".
Webserver request body limit. nginx has a client_max_body_size directive (default 1M, painfully low for media uploads). Apache rarely caps this by default, but reverse proxies, load balancers and CDNs (Cloudflare, in particular, has a 100M cap on free plans, 200M on Pro, 500M on Business) all enforce their own ceilings. Symptom: a "413 Request Entity Too Large" page that does not look like WordPress at all, because WordPress never received the request.

The actual maximum upload size is the lowest of all four. WordPress shows the effective limit on the upload page itself: open Media, Add New in the admin and look for the small "Maximum upload file size" line below the upload area.

How much do you actually need?

A practical mental model:

32M. Enough for typical images, PDFs and small audio files. The default on conservative shared hosts.
64M. Comfortable for most editorial sites. Handles photo bursts from a modern camera, larger PDFs and short video clips.
128M to 256M. The right range for sites that regularly upload video, large PSD files, design assets, or theme and plugin zip files for a self managed install.
Above 256M. Mostly relevant for video heavy sites, podcast feeds with large audio files, or course platforms with downloadable lecture material. Worth thinking about whether the file actually needs to live on the WordPress server, or whether a service like Vimeo, YouTube, Bunny Stream or a dedicated S3 bucket is the better fit. WordPress is not optimized for serving large media files at scale.

One detail people miss: WordPress also has its own internal cap. By default it does not impose a size limit beyond what PHP allows, so on most hosts the PHP settings are the only thing in play. The upload_size_limit filter exists if you want to set a project specific cap (useful in multisite to give different roles different limits), but it can only lower the effective limit, never raise it past PHP.

Option 1: Raise PHP limits via your hoster's panel

Almost always the right starting point. Most hosts in 2026 expose the relevant settings in their dashboard, and changes take effect within seconds.

cPanel (IONOS, Hostinger, many resellers)

Go to MultiPHP INI Editor, select your domain, and adjust:

upload_max_filesize to your target value (e.g. 128M)
post_max_size to the same or higher (e.g. 128M)
max_execution_time to at least 300 seconds for large files
max_input_time to the same value
memory_limit to 256M or higher (uploads load briefly into memory during processing)

Save. The change is live immediately.

Plesk (All Inkl, DomainFactory, many German hosts)

Open the domain in Plesk, click PHP Settings, scroll to "Performance and security settings". The fields are the same as for cPanel. Save and the values apply on the next request.

Managed WordPress hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

These hosts almost always ship with sensible defaults already (typically 64M to 128M). If the limit is still too low for your use case, the dashboard usually has a slider or input field. A few hosts (WP Engine, Pressable) cap the absolute maximum and require a support ticket beyond a certain size, usually because their upload pipeline pre validates files against a CDN. Those tickets get answered within hours, not days.

Option 2: .user.ini in the WordPress root

If your host runs PHP via FastCGI or PHP FPM (which is essentially every modern host), but does not expose a settings panel, you can drop a .user.ini file directly into the WordPress root directory:

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

PHP picks up .user.ini automatically. The only quirk is a default cache time of five minutes (controlled by the user_ini.cache_ttl setting), so changes do not always take effect on the very next request.

Verify with the WordPress Site Health page: Tools, Site Health, Info, Server shows the active upload_max_filesize and post_max_size. If the values still match the old defaults after ten minutes, the host either disables .user.ini support or runs PHP in a mode that ignores it. Continue with Option 3.

Option 3: php.ini on a self managed server

On a VPS or dedicated server where you control PHP directly, edit the active php.ini. Find it with php --ini on the command line. The path varies by distribution and PHP version (typically /etc/php/8.2/fpm/php.ini on Debian or Ubuntu, /etc/php.ini on CentOS or RHEL).

Adjust the same five values as in Option 1, then reload PHP FPM:

sudo systemctl reload php8.2-fpm

(Adjust the version number to match your install.) On Apache with mod_php, restart Apache instead. The change applies immediately, no further action needed.

Option 4: nginx client_max_body_size

This is the one that catches a lot of people on self managed nginx. PHP can be configured to accept 1GB uploads, but if nginx is still capped at 1M (the default), the upload never reaches PHP at all. The browser shows a generic "413 Request Entity Too Large" error, often without any indication that nginx is responsible.

Add the directive to the server block of your site, or globally in the http block of nginx.conf:

client_max_body_size 128M;

Reload nginx with sudo nginx -t && sudo systemctl reload nginx. The value should match or exceed your PHP post_max_size. There is no harm in setting it slightly higher; the actual limit is still PHP.

Option 5: Apache with .htaccess (legacy)

On older Apache setups running mod_php (rare on modern hosting, common on legacy servers), you can put the PHP directives directly into .htaccess in the WordPress root:

php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

If your host runs PHP via FastCGI or PHP FPM (which is essentially every modern host), this directive throws a 500 error or is silently ignored. Use .user.ini from Option 2 instead.

Option 6: When the limit is at the CDN or proxy layer

If you have configured PHP and the webserver to allow 256M uploads, but the upload still fails at, say, 100M, the bottleneck is somewhere in front of the WordPress server. Common culprits:

Cloudflare caps body size by plan: 100M on Free, 200M on Pro, 500M on Business, 500M on Enterprise (raised on request). For larger uploads either upgrade the plan, exclude the WordPress admin from the proxy by setting the DNS record to "DNS only" for /wp-admin/ via a Page Rule, or use a direct subdomain that bypasses Cloudflare for uploads.
Cloudways has a varnish layer that defaults to a low body size limit. Their dashboard exposes the setting under "Application Settings, Server Configurations".
Reverse proxies set up in front of nginx (HAProxy, Traefik) all have their own body size limits that need raising in their respective config files.
Some firewalls and security plugins at the WAF level (Sucuri, Wordfence Premium with cloud WAF) cap upload sizes by default. Their settings panel has a separate option for this.

The diagnostic trick: try the upload from inside the server itself using curl with a local file. If the upload works locally but fails through the public URL, the limit is at a proxy or CDN layer, not in PHP.

How to verify the new limits are active

Open Tools, Site Health, Info in the WordPress admin.
Expand the Server section. Look for upload_max_filesize, post_max_size, max_execution_time and memory_limit. They should all reflect the new values.
For a faster check, open Media, Add New. The "Maximum upload file size" line at the bottom of the upload area should show the new effective limit.
Try the actual upload that triggered the issue. If it still fails, note exactly which error message you get; that points to which of the four limits is still too low.

What to do when the file is genuinely too large for HTTP upload

Above 500M to 1GB, browser uploads stop being practical regardless of server settings. The TCP connection gets unstable, intermediate proxies time out, and a single network hiccup means starting over. Two saner alternatives:

Upload via SFTP and import via WordPress. Place the file directly into wp-content/uploads/YEAR/MONTH/ via SFTP, then use a plugin like Add From Server or Media Sync to register it in the media library. WordPress generates the metadata and thumbnails as if you had uploaded normally.
External media services. For video specifically, Vimeo, Bunny Stream, Cloudflare Stream and YouTube all handle hosting and adaptive streaming far better than WordPress core. Most modern themes and page builders embed these natively, including auto generated thumbnails. Same logic for audio (Soundcloud, Spotify for podcasters) and large file downloads (S3 with a CloudFront or Bunny CDN in front).

Hosting a 5GB raw video on shared WordPress hosting and serving it directly is technically possible but rarely the right move. The bandwidth costs, the lack of adaptive bitrate, and the strain on a single PHP worker per simultaneous viewer all point toward dedicated media hosting.

Common mistakes to avoid

Raising upload_max_filesize without raising post_max_size alongside. The upload silently fails because the entire POST request exceeds the lower of the two. Always change them together.
Setting absurdly high values "to be safe". A 4G upload limit on a server with 4GB total RAM is a denial of service vector. PHP loads parts of the upload into memory during processing. Pick a value that reflects what you actually upload, plus headroom.
Forgetting max_execution_time. A 500MB upload on a 10 Mbit/s connection takes about seven minutes. If max_execution_time is the default 30 seconds, the request gets killed mid upload regardless of size limits.
Editing the wrong php.ini. A common mistake on systems with multiple PHP versions installed (e.g. 7.4 and 8.2 both present, but only one active). The php --ini command on the command line might point to a different php.ini than the one PHP FPM uses for the webserver. Site Health is the authoritative source.

For most cases, two minutes in the hoster panel raising five values to sane defaults solves the problem permanently. The error messages around upload size limits are unfortunately phrased so that they sound like obscure technical issues, but the actual fix is mechanical and well documented. Once the limits are sized to your actual workload, this is one of the WordPress topics that does not need to come up again.