You drag a photo into the Media Library, the progress bar fills up, and then WordPress replaces it with two useless words: “HTTP error.” No code, no explanation, no hint of what went wrong. The WordPress HTTP error uploading images is one of the most frustrating messages on the platform because it’s a catch-all: WordPress knows the upload failed, but it doesn’t know (or won’t say) why.
The good news: the list of real causes is short, and almost all of them are fixable in a few minutes. This guide walks through them in the order worth trying, from the 10-second fixes to the server-level ones.
Why Does WordPress Say “HTTP Error” When I Upload an Image?
WordPress shows “HTTP error” when the server returns an error response to the media uploader instead of a successful result. The file usually reaches the server fine; what fails is the processing step afterward, where WordPress resizes the image and generates thumbnails. That’s why the most common causes are low PHP memory, the image editing library (Imagick or GD), oversized images, and security rules blocking the request.
Every image you upload to WordPress gets processed several times. WordPress creates a thumbnail, medium, medium-large, and large version, plus any extra sizes your theme and plugins register. A single 12-megapixel phone photo can trigger eight or more resize operations in one request. If the server runs out of memory, hits a time limit, or the image library chokes during any of them, the uploader just gets back a failed response and shows the generic error.
Fix 1: Wait, Refresh, and Try Again
The first fix for the WordPress HTTP error is the boring one: wait a minute, reload the page, and upload the image again. A temporary server spike or an expired login session can cause a one-off failure, and if the second attempt works, there’s nothing to fix.
Expired sessions are sneakier than they sound. If the dashboard tab has been open for hours, WordPress may have logged you out in the background without showing the login popup. Log out, log back in, and retry before touching any settings.
Fix 2: Rename the File and Check the Format
Rename the image to a plain filename with only lowercase letters, numbers, and hyphens, like team-photo-2026.jpg. Apostrophes, accented characters, and special symbols in filenames are a known trigger for the upload HTTP error, and renaming takes five seconds.
Format matters too. iPhone photos are often HEIC files. According to the official WordPress core team announcement, WordPress 6.7 and later automatically convert HEIC uploads to JPEG, but only when the server’s Imagick build supports HEIC. On servers without that support, WordPress asks you to convert the file manually. If a HEIC upload fails, export the photo as JPEG or WebP and try again.
Fix 3: Shrink the Image Before Uploading
Resize huge images before they ever touch WordPress. A 6000×4000 pixel photo needs far more memory to process than a 2000×1333 version, and almost no website layout displays anything wider than about 2000 pixels anyway.
Since WordPress 5.3, core automatically scales down images larger than 2560 pixels (the “big image threshold”), but that scaling still happens on the server, inside the same request that’s failing. Shrinking the image locally removes the heavy lifting entirely. Pixel dimensions matter more than file size here: a 3MB image at 6000 pixels wide is harder for the server than a 5MB image at 2000 pixels wide.
Uploading pre-sized images is just good practice anyway. The WordPress image optimization guide covers the right dimensions and formats for different parts of a page.
Fix 4: Increase the PHP Memory Limit
Low PHP memory is the single most common cause of the WordPress HTTP error on image uploads. Image processing loads the whole uncompressed image into memory, so a large photo can need well over 100MB of RAM during resizing. Raising the WordPress memory limit to 256M fixes the error on a large share of sites.
Add this line to wp-config.php, above the line that says /* That's all, stop editing! */:
define( 'WP_MEMORY_LIMIT', '256M' );One catch: WP_MEMORY_LIMIT can’t go higher than the server’s own PHP memory_limit. If the host caps PHP at 128M, the wp-config.php setting does nothing beyond that. Check the real value under Tools > Site Health > Info > Server, and raise it in your hosting panel’s PHP settings if needed. The full process, including how to tell whether memory is really the problem, is in the guide to the WordPress memory exhausted error.
Fix 5: Switch the Image Editor From Imagick to GD
WordPress processes images with one of two PHP libraries: Imagick (ImageMagick) or GD. WordPress prefers Imagick when it’s available, but Imagick is more resource-hungry and more likely to fail on shared hosting. Forcing WordPress to use GD instead is one of the most reliable fixes for a persistent HTTP error.
Check which editor your site is using under Tools > Site Health > Info > Media Handling. If it says WP_Image_Editor_Imagick, add this snippet to your child theme’s functions.php or a code snippets plugin:
add_filter( 'wp_image_editors', function( $editors ) {
return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );This doesn’t remove Imagick. It just moves GD to the front of the line, so WordPress tries GD first and falls back to Imagick only if GD can’t handle the file.
An alternative, if you want to keep Imagick, is limiting it to a single thread. On Apache servers, add this to the top of .htaccess:
SetEnv MAGICK_THREAD_LIMIT 1Imagick’s multi-threading can trip resource limits on shared hosts, and a single thread is slower but far more stable.
Imagick vs GD: Which Should WordPress Use?
Imagick produces slightly better resize quality and supports more formats, while GD is lighter and more predictable on limited hosting. For most small business sites on shared hosting, GD is the safer default.
| Feature | Imagick (ImageMagick) | GD |
|---|---|---|
| WordPress default | Yes, when installed | Fallback |
| Memory and CPU use | Higher | Lower |
| Resize quality | Slightly sharper | Good enough for most sites |
| HEIC conversion (WP 6.7+) | Yes, if the build supports it | No |
| Best for | VPS or managed hosting with headroom | Shared hosting, upload errors |
Fix 6: Check the Upload Size and Server Limits
If the image is larger than the server’s maximum upload size, the upload can fail with a generic HTTP error instead of a clear size warning. Check the current limit on Media > Add New, where WordPress shows “Maximum upload file size” under the upload box.
The limit is controlled by PHP’s upload_max_filesize and post_max_size settings, and sometimes by a separate web server limit like Nginx’s client_max_body_size. Sites behind Cloudflare also have a per-request upload cap set by the Cloudflare plan. The step-by-step methods for raising these are in the guide on how to increase the WordPress max upload size.
Fix 7: Deactivate Image Optimization and Security Plugins
Image optimization plugins hook directly into the upload process, so a misbehaving one can break every upload. Security plugins and firewalls can also block the upload request as “suspicious.” Temporarily deactivating these plugins is the fastest way to confirm whether a plugin is behind the WordPress image upload error.
Start with the obvious suspects: compression plugins (ShortPixel, Imagify, Smush, EWWW), WebP or AVIF converters, and security plugins like Wordfence. Deactivate one, retry the upload, and repeat. If no single plugin stands out, the full method for isolating a WordPress plugin conflict works the same way here, and switching briefly to a default theme like Twenty Twenty-Five rules out the theme too.
Fix 8: Fix Uploads Folder Permissions
WordPress can’t save images if it doesn’t have permission to write to the wp-content/uploads folder. The correct permission for the uploads folder and its subfolders is 755, and files inside should be 644.
Permissions problems usually appear after a site migration or a server change. Check them through your hosting file manager or an FTP client like FileZilla (right-click the folder, choose “File permissions”). Avoid setting anything to 777. It might make the error disappear, but it also lets any process on the server write to that folder, which is a security hole.
Fix 9: Check ModSecurity and Ask Your Host
ModSecurity is a server-level firewall many hosts run by default, and its rules sometimes flag WordPress upload requests to async-upload.php as an attack. If none of the earlier fixes worked, the server’s error log will usually show whether ModSecurity blocked the request.
Some hosting panels let you toggle ModSecurity yourself, but the better move is contacting the host with the exact time of the failed upload. They can find the blocked rule and whitelist it for your site instead of disabling the firewall entirely. This is also the point where hosting quality starts to show: if a host can’t support basic image uploads with 256MB of memory, the hosting itself is the problem.
How Do I Stop the HTTP Error From Coming Back?
Preventing the WordPress HTTP error comes down to giving the server less work per upload and more room to do it. Resize images to around 2000 pixels wide before uploading, keep PHP memory at 256M, and remove image sizes your theme or plugins register but never use.
That last point gets overlooked. Every registered image size means another resize operation on every upload. Page builders, WooCommerce, and some themes each add their own sizes, and the total can quietly climb past a dozen. Fewer sizes means faster, lighter uploads and a smaller uploads folder.
The Bottom Line
The WordPress HTTP error looks vague, but it almost always means the same thing: the server couldn’t finish processing the image. Try the quick fixes first (retry, rename, resize), then raise PHP memory and switch the image editor to GD. Those two server-side changes resolve the large majority of cases. If uploads still fail after that, the cause is a plugin, a permission, or a firewall rule, and the server error log will point to which one.
Frequently Asked Questions
The WordPress HTTP error appears when the server fails while processing an uploaded image, usually during resizing and thumbnail generation. The most common causes are a low PHP memory limit, the Imagick image library using too many resources, very large image dimensions, plugin conflicts, and server firewalls like ModSecurity blocking the request.
When only some images fail, the cause is almost always the images themselves: large pixel dimensions that need more memory to process, an unsupported format like HEIC, or special characters in the filename. Resizing the image to around 2000 pixels wide and renaming it with plain letters and hyphens usually fixes it.
Yes, switching WordPress to the GD image editor is safe and fully supported through the wp_image_editors filter. GD uses fewer server resources than Imagick, with a small trade-off in resize sharpness and no HEIC conversion support, and existing images in the Media Library are not affected.
A PHP memory limit of 256M is enough for WordPress to process typical image uploads, including large phone photos. Set it with define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); in wp-config.php, and make sure the server’s own PHP memory_limit is at least that high, because WordPress can’t exceed the server cap.
Yes, image optimization plugins and security plugins are common causes of the WordPress HTTP error because they hook into or inspect the upload request. Deactivating them one at a time and retrying the upload identifies which plugin is responsible.
Leave a Reply