Fix the WordPress “HTTP Error” on Image Upload

You drag a photo into the WordPress Media Library and get a flat, unhelpful “HTTP error” with no detail. Nine times out of ten the server ran out of memory while resizing the image. This DevAnswers fix starts with that memory limit, then walks the other two layers that throw the same error if it persists.

Quick fix: raise the PHP memory limit #

WordPress resizes every upload in PHP, and that needs far more memory than the file’s size on disk suggests. Give PHP more headroom by raising memory_limit. Where it lives depends on how your server runs PHP: a traditional Apache + mod_php LAMP install keeps it in /etc/php/8.3/apache2/php.ini, while PHP-FPM (always the case on nginx, and increasingly used with Apache too) uses /etc/php/8.3/fpm/php.ini. Run ls /etc/php/ for your version (our guide to finding your php.ini helps if you are unsure which file your site loads), then open whichever matches your setup:

# Apache + mod_php (the classic LAMP stack):
sudo nano /etc/php/8.3/apache2/php.ini

# PHP-FPM (nginx, or Apache via FPM):
sudo nano /etc/php/8.3/fpm/php.ini

Find memory_limit and raise it, then save and exit:

memory_limit = 256M

Save and exit (press CTRL + X, press Y, then press ENTER)

Then restart whatever runs PHP so the change takes effect:

# Apache + mod_php:
sudo systemctl restart apache2
# PHP-FPM:
sudo systemctl reload php8.3-fpm

On shared hosting with no shell, raise WordPress’s own memory limit in wp-config.php instead (above the “That’s all, stop editing” line). Image processing runs in the admin area, so the constant that governs uploads is WP_MAX_MEMORY_LIMIT, not the front-end WP_MEMORY_LIMIT:

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

Save and exit (press CTRL + X, press Y, then press ENTER)

Then retry the upload. For most sites, that is the whole fix.

These commands are for Debian and Ubuntu. On RHEL-family systems (Rocky, AlmaLinux) the idea is identical but the names differ: install with dnf, the services are php-fpm and httpd, and PHP’s config lives at /etc/php.ini.

Why a large image triggers “HTTP error” #

The error is so vague because it is the browser’s generic report that WordPress’s background AJAX call failed, not a specific message. The most common reason that call dies is memory: a 12-megapixel photo might be only 4 MB on disk, but uncompressing it into a bitmap so WordPress can generate the thumbnail sizes can need hundreds of megabytes of RAM. Exceed memory_limit and PHP is killed mid-resize, leaving the browser with nothing but “HTTP error.”

To confirm memory is the culprit, watch your web server’s error log while you reproduce the upload, an Allowed memory size … exhausted line is the smoking gun:

# Apache:
sudo tail -f /var/log/apache2/error.log
# nginx:
sudo tail -f /var/log/nginx/error.log

Still failing? Check the other two layers #

If more memory did not help, the same error can come from two completely different layers. Work through both.

1. The upload-size limits #

Before WordPress ever processes the image, PHP and the web server each cap how large an upload can be. If any of them is smaller than your image, the upload is rejected. Raise the PHP upload limits in the same php.ini (keep post_max_size a little larger than upload_max_filesize, since the POST carries the file plus form fields):

upload_max_filesize = 64M
post_max_size = 72M

Save and exit (press CTRL + X, press Y, then press ENTER)

Then raise the web server’s own body limit. On nginx, add to the server block:

client_max_body_size 72M;

Save and exit (press CTRL + X, press Y, then press ENTER)

On Apache, it is LimitRequestBody (in bytes). Keep the web-server limit at least as large as your post_max_size so it never rejects an upload PHP would accept, and reload the web server afterwards. A too-low server limit usually shows as a 413 rather than the HTTP error, but a borderline PHP limit lands you right back here.

2. The image library #

WordPress edits images with the Imagick PHP extension when it is installed, and falls back to GD otherwise. Imagick is more memory-efficient and handles large images more reliably, so installing it often fixes uploads that GD chokes on:

sudo apt install php-imagick
# then restart PHP, mod_php: sudo systemctl restart apache2, FPM: sudo systemctl reload php8.3-fpm

Check which one WordPress sees under Tools › Site Health › Info › Media Handling.

Other causes worth ruling out #

If memory, upload limits, and Imagick are all fine, run down the usual suspects:

Very large dimensions. Since WordPress 5.3, uploads wider or taller than 2560px are scaled down automatically (the big_image_size_threshold filter). That scaling still happens in PHP, so an enormous image can hit the memory wall even with the limits raised, resize the photo before uploading, or raise memory further.

To raise that 2560px threshold (or return false to switch the scaling off entirely), add a filter to your theme’s functions.php:

add_filter( 'big_image_size_threshold', function() { return 3840; } );

A plugin or theme conflict. An image-optimisation or security plugin can intercept the upload. Temporarily switch to a default theme and deactivate plugins; if the upload works, re-enable them one at a time to find the culprit.

mod_security or a host rule. On managed or shared hosting, a server-side firewall (mod_security) can silently block the upload request. If nothing on your side explains it, ask the host to check their logs.

Verify the Fix #

Go to Media › Add New Media File and upload the image that failed before:

uploaded-photo.jpg | 2.4 MB | uploaded, thumbnails generated

A successful upload with its thumbnail sizes generated means the fix held. If it still fails, watch your web server’s error log (/var/log/apache2/error.log or /var/log/nginx/error.log) during the upload, the exact error there (memory, a fatal in a plugin, a permission issue) tells you which layer to revisit.