WordPress Media Upload Errors: Fix File Size & Permissions

You drag a photo into the WordPress media library and instead of a preview, you get a vague red banner: "HTTP error." Or the upload bar fills up and just stalls. Or it goes through fine but the image looks half-rendered with no thumbnails. None of these tell you what actually broke - so let's go through the real causes in order of how often we see them, and how to fix each one on cPanel hosting.

What "upload failing" usually looks like

Media upload problems in WordPress show up a few different ways, and the symptom is a decent clue to the cause:

• "HTTP error" with no other detail - almost always a server-side limit or a security rule blocking the request.
• Upload sits at a specific percentage and times out - usually a file size or execution time limit.
• "The uploaded file exceeds the upload_max_filesize directive" - self-explanatory, and the easiest one to fix.
• Image uploads but thumbnails/sizes are missing - a PHP image library issue, not a size limit at all.
• Upload works in one browser tab and fails on a bigger file - confirms it's size-related, not a plugin conflict.

Cause 1: File size limits (upload_max_filesize / post_max_size)

WordPress shows you the effective upload limit at the bottom of Media → Add New: "Maximum upload file size: 64 MB" (or whatever your host allows). That number comes straight from PHP, not from WordPress itself - so changing anything in wp-admin won't move it.

Two PHP directives control this, and both need to be big enough:

• upload_max_filesize - the max size of a single file.
• post_max_size - the max size of the entire form submission. This must be equal to or larger than upload_max_filesize, or uploads will silently fail even though the file itself is small enough.

Fix via cPanel MultiPHP INI Editor

1. In cPanel, open MultiPHP INI Editor.
2. Select your domain from the dropdown.
3. Switch to Editor Mode and set:

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

Click Save. No restart needed - PHP-FPM picks it up on the next request. If your account doesn't have MultiPHP INI Editor, add the same lines to a .user.ini file in public_html instead; it applies the same way on most cPanel PHP-FPM setups.

Skip raising max_execution_time and max_input_time and you'll trade one error for another - the upload passes the size check but times out mid-transfer on a slow connection.

Cause 2: Wrong permissions on wp-content/uploads

If small files upload fine but WordPress can't write the resized copies afterward, permissions are the usual suspect. WordPress needs to write into the uploads directory and every year/month folder inside it.

Correct ownership and permissions from SSH:

cd public_html/wp-content
find uploads -type d -exec chmod 755 {} \;
find uploads -type f -exec chmod 644 {} \;
chown -R youruser:youruser uploads

In cPanel File Manager, right-click uploads → Permissions and confirm folders are 755 and files are 644. Anything at 777 is a red flag too - it uploads fine but it's an open door for anyone who finds a way to write to that folder.

Cause 3: PHP memory_limit running out during image processing

Resizing a large photo into WordPress's various thumbnail sizes is memory-intensive - more so than the file size itself suggests. A 12MB photo from a modern phone can need well over 128MB of PHP memory to process into all the registered image sizes. If memory_limit is too low, the upload appears to "complete" but the thumbnails never generate, or you get a fatal error in the PHP log.

Raise it in wp-config.php, just above /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

If your host caps PHP's actual memory_limit lower than that in php.ini, the WordPress constant can't override it - check MultiPHP INI Editor and set memory_limit = 256M there too.

Cause 4: .htaccess or mod_security blocking the request

A generic "HTTP error" with no size or memory message in the logs usually means the request never reached WordPress at all - it got blocked before that, either by a rule in .htaccess or by ModSecurity.

Check for it:

1. In cPanel, open Metrics → Errors and look for a 403 tied to async-upload.php or admin-ajax.php at the time you tried uploading.
2. If your plan includes ModSecurity under Security in cPanel, check its log for a rule ID hit around that timestamp - editor plugins and certain file types can trip generic XSS or file-upload rules.
3. Ask us to whitelist that specific rule ID for your domain rather than disabling ModSecurity outright - a blanket disable removes protection you actually want.

Also check your theme or a security plugin hasn't added a restrictive rule to .htaccess in wp-content/uploads - some hardening guides add a rule there to block PHP execution, which is good, but an overly broad rule can catch legitimate uploads too. Look for a stray Deny from all without the accompanying <FilesMatch> scoping it to PHP files.

Cause 5: A plugin intercepting the upload

Image optimization plugins, CDN/offload plugins (that push uploads straight to S3 or similar), and some security plugins hook into the upload process. When one of them errors out, WordPress reports it as a generic upload failure with no useful detail in the browser.

Isolate it fast:

• Deactivate all plugins except WordPress core, then try the upload again.
• If it works, reactivate plugins one at a time, testing an upload after each, until it breaks again.
• Check that plugin's own settings for an API key, storage bucket, or optimization service that might be misconfigured or rate-limited.

Cause 6: Missing or misconfigured GD/Imagick extension

If the original file uploads but no thumbnail sizes are generated at all - not even the full-size preview rendering - the server's image library is the problem, not WordPress. WordPress uses the GD library by default and falls back to Imagick if available.

Check what's active under Tools → Site Health → Info → Media Handling in wp-admin. If it shows no active editor, ask us to enable the gd or imagick PHP extension for your account - on cPanel this is usually a checkbox under Select PHP Version → Extensions.

Quick diagnostic table

Prevention checklist

• Set upload_max_filesize and post_max_size a good margin above what you actually need - media libraries only grow.
• Keep memory_limit at 256M or higher on any site handling photos from modern cameras or phones.
• Resize large images before uploading where possible - it's faster for you and lighter on the server either way.
• Review ModSecurity rule hits occasionally instead of only when something breaks - a rule can start blocking a legitimate plugin after an update on either side.
• Keep image optimization and offload plugins updated - most upload-interception bugs get fixed quickly once reported.

If you've checked all of the above and uploads still fail, send us the exact error text and the timestamp of a failed attempt - we can pull the raw PHP and ModSecurity logs on our end and usually spot it in a couple of minutes.