WordPress Media Upload Fails (HTTP Error, 413, or Images Won’t Process): Fix It Fast

When WordPress media upload fails, it can feel like the whole site is fighting you. You click Add New in the Media Library, select an image, and then… an unhelpful “HTTP error” pops up. Or you see 413 Request Entity Too Large. Or the upload succeeds, but WordPress says the image “failed to process” (or never generates thumbnails, or stalls on “Crunching…” forever).

The good news: these issues are usually caused by a handful of predictable settings—upload limits, web server rules, WAF/security blocks, filesystem permissions, or broken image libraries (GD/Imagick). This guide walks you through a practical, “check the most likely stuff first” workflow that fixes the majority of cases.

If you want a pro to handle the server-side changes safely (especially on production sites), WP Fix It’s team can knock out stubborn upload errors quickly—start here: WP Fix It homepage or jump straight to the one-time repair option: Site Fix Service.

What the errors usually mean

1) “HTTP error” (WordPress uploader)

This is WordPress’s generic way of saying “the upload request failed.” It doesn’t identify the root cause by itself. Common triggers:

File exceeds a server limit (PHP / web server / proxy / CDN)
Security layer blocks the request (ModSecurity/WAF)
Server times out or runs out of memory while generating thumbnails
Broken image processing (Imagick/GD)
Permissions/temp directory issues

2) “413 Request Entity Too Large”

A reverse proxy, web server, or CDN is rejecting your upload because the request body is bigger than allowed.

Typical culprits:

Nginx client_max_body_size
Apache LimitRequestBody (less common)
Cloudflare / proxy limits (depends on plan/config)
Hosting control panel limits

3) “Images won’t process” / “Failed to process image”

Your file may upload, but WordPress can’t create image subsizes (thumbnails), convert formats, or read metadata. Common triggers:

Insufficient PHP memory
Imagick or GD missing/misconfigured
Corrupt image, unusual color profile, or huge dimensions
Plugin conflict (optimization, security, offload, caching)
Lack of disk space or permission to write uploads

Step 0: Confirm the real maximum upload size (WordPress vs server)

In WordPress Admin:

Go to Media → Add New and look at the fine print: “Maximum upload file size: X MB”

That number is WordPress reporting what PHP thinks is allowed. It does not include limits enforced by Nginx/Apache/CDN/proxies, which can still trigger 413 even if WordPress shows a larger number.

Also check:

Tools → Site Health → Info → Media Handling (may reveal library details and image editor support)

Helpful reference:

WordPress support docs on media: WordPress.org Support

Step 1: Fix the most common cause—PHP upload limits

These are the PHP directives that usually matter:

upload_max_filesize
post_max_size (must be >= upload_max_filesize)
memory_limit (often needs to be higher for big images and thumbnail generation)
max_execution_time (processing large images can be slow)

Option A: Update `php.ini` (best if you have access)

Add or adjust:

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

Restart PHP-FPM / web server if required.

PHP directive documentation:

Option B: Use `.user.ini` (common on shared hosting)

Create/edit .user.ini in the WordPress root:

upload_max_filesize=64M
post_max_size=64M
memory_limit=256M
max_execution_time=300

Changes can take a few minutes to apply.

Option C: Try `.htaccess` (Apache with mod_php)

Add to .htaccess:

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

If this triggers a 500 error, your host likely doesn’t allow these directives in .htaccess.

Step 2: If you see 413, fix web server / proxy limits (Nginx, Apache, CDN)

When WordPress media upload fails specifically with 413, PHP settings alone often won’t help.

Nginx: set `client_max_body_size`

In your server block (or http block):

server {
  ...
  client_max_body_size 64m;
}

Then reload Nginx:

nginx -t && systemctl reload nginx

Nginx directive reference:

Nginx client_max_body_size

Apache: check `LimitRequestBody`

This is less common, but if present, raise it:

LimitRequestBody 67108864

Apache directive reference:

Apache LimitRequestBody

Reverse proxies & CDNs (Cloudflare, etc.)

If you route traffic through a proxy/CDN, the upload can be blocked before it even hits your server.

Cloudflare docs can help you confirm request limits and troubleshooting:

Cloudflare Support / Docs

If you suspect a proxy limit, a quick test is to pause the proxy (temporarily “DNS-only”) and try uploading again. If uploads work only when bypassing the proxy, you’ve found your choke point.

Step 3: Fix “HTTP error” by identifying the real failure

Turn on WordPress debug logging (temporarily)

In wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Try the upload again, then check:

/wp-content/debug.log

WordPress debugging reference:

WordPress.org Debugging

Check server error logs

Depending on your setup:

Nginx: /var/log/nginx/error.log
Apache: /var/log/apache2/error.log (or distro equivalent)
PHP-FPM: /var/log/php*-fpm.log

If the log shows memory exhaustion, timeouts, forbidden rules, or missing libraries, you can jump directly to the correct fix below.

Step 4: When images upload but won’t process (thumbnail generation fails)

If WordPress media upload fails after upload—especially when generating thumbnails—these are the top causes.

4.1 Increase PHP memory (often the real fix)

Big images (or modern formats) can require a lot of memory to decode and resize.

Try:

memory_limit = 256M (or 512M for very large images / heavy plugins)

Also in WordPress, you can set:

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

4.2 Check Imagick vs GD support

WordPress uses either Imagick or GD for image processing.

If Imagick is missing or broken, WordPress may fail to resize.
If GD is missing, the same.

Your host controls this at the PHP extension level.

Docs:

4.3 HEIC/HEIF, WebP, AVIF edge cases

Modern formats can be tricky depending on server libraries.

If you’re uploading HEIC from an iPhone, convert to JPG/PNG as a test.
If you’re uploading AVIF, ensure your stack supports it (Imagick/libheif or GD with the right build).

A fast sanity test: upload a small JPG (like 200 KB).
If JPG works but AVIF/HEIC fails, this is format support—not WordPress itself.

4.4 Reduce insane dimensions (pixels, not file size)

An image can be “only 8 MB” but be 12000×9000 pixels. Resizing that can blow memory.

Fix:

Resize to a sane max dimension (e.g., 2560 px wide for typical web use)
Re-upload

Step 5: Fix filesystem permissions and temp directory issues

If WordPress can’t write to wp-content/uploads, you’ll get inconsistent uploader failures.

Check uploads folder permissions

Typical safe defaults:

Folders: 755
Files: 644

Make sure the web server user owns the uploads directory (varies by host).

WordPress file permissions reference:

WordPress.org File Permissions

Check disk space and inode limits

If your server is out of space—or your shared host has hit inode quotas—uploads can fail or processing can silently stop.

Confirm PHP temp directory

If upload_tmp_dir is misconfigured or not writable, uploads can fail before they reach WordPress.

Step 6: Security/WAF blocks (ModSecurity, firewall rules, “false positives”)

If logs show 403/406 errors during upload, or you’re on managed hosting, it may be a WAF rule blocking multipart upload requests.

Common signs:

It fails only for certain filenames or file types
It fails only when you upload from wp-admin (but SFTP works)
The server error log mentions ModSecurity rule IDs

Fix options:

Whitelist the rule for wp-admin/async-upload.php
Temporarily disable ModSecurity for that path (hosting panel dependent)
Ask your host to whitelist WordPress media endpoints

If you suspect the site is compromised (malware can also break admin actions and uploads), it’s worth scanning and cleaning before you keep tweaking server rules. WP Fix It has a full cleanup offering here: How to Remove WordPress Malware and a deeper guide here: Step-by-Step WordPress Malware Removal.

Step 7: Plugin/theme conflicts that break the uploader or processing

Some plugins commonly interfere with uploads:

Image optimization plugins (especially ones that “process on upload”)
Offload/media library plugins (S3, CDN offload)
Security plugins (blocking admin-ajax or upload endpoints)
Caching/minification plugins (rare, but can break admin JS)

Quick conflict test

Switch to a default theme (like Twenty Twenty-Four)
Disable all plugins
Try uploading a small JPG
Re-enable plugins one by one until it breaks

If uploads only fail when one plugin is active, you’ve found the trigger.

If your site is in a fragile state and you’d rather not risk downtime, consider a guided fix: Fast 24/7 WordPress Support.

Step 8: Browser and network gotchas (worth 2 minutes)

Not the most common, but easy to test:

Try another browser
Disable browser extensions
Try a different network (some corporate proxies limit large POST requests)
Clear cache and log in again

If the issue disappears on another network, you may be dealing with a proxy restriction upstream.

Step 9: A practical “fix order” checklist (use this to avoid rabbit holes)

When WordPress media upload fails, run this order:

Upload a small JPG (baseline test)
Confirm WordPress max upload size in Media → Add New
Raise PHP limits (upload_max_filesize, post_max_size, memory_limit)
If 413, raise Nginx/Apache/proxy limits
Check debug log + server error log for memory/timeouts/WAF blocks
If “won’t process,” verify Imagick/GD and increase memory
Check uploads permissions and disk space
Disable plugins / switch theme to find conflicts

This sequence fixes most sites without guesswork.

Common scenarios and the exact fix

Scenario A: WordPress says max upload is 2 MB

Fix PHP configuration (php.ini, .user.ini, host panel “PHP Options”) and raise:

upload_max_filesize
post_max_size

Scenario B: WordPress shows 64 MB, but you still get 413

Fix Nginx client_max_body_size or CDN/proxy limit.

Scenario C: Upload succeeds, but thumbnails never generate

Increase:

memory_limit
max_execution_time
Then verify Imagick/GD availability.

Scenario D: Only certain images fail (from iPhone, AVIF, HEIC)

Convert to JPG/PNG and re-test. If that works, add proper server support for that format or change workflow.

Prevention tips so you don’t fight this again next month

Keep images web-friendly (dimensions + file size)
Maintain a reasonable PHP memory limit
Avoid stacking multiple “optimize on upload” plugins
Keep WordPress core/plugins updated
Monitor uptime and site health (WP Fix It even has a guide for monitoring): Free WordPress Up Time Monitor

If your site needs a broader stability check (uploads are often a symptom of deeper hosting/config issues), a tune-up can help: WordPress Tune Up Service.