Skip to content
WordPress Support

WordPress HTTP Error When Uploading Images: How to Fix It

"HTTP error" in the Media Library usually means the server failed while resizing your image. Here is how to find out why and fix it, starting with the steps that change nothing.

Two people looking at a laptop together
8 sections · 7 min read
In this article · 8 sections

You drag a photo into the Media Library, the progress bar fills, and then the upload box turns red with two words: “HTTP error.” No explanation, no code, nothing to search for. Try again and it may fail the same way, or it may suddenly work, which is even more confusing.

That vague message is WordPress telling you the server answered the upload with something it did not expect. The image never finished being processed. The good news is that the list of reasons is short, and most of them can be checked without touching any code.

What the error looks like now

On older installs you only ever see “HTTP error.” under the file name. Newer versions of WordPress are a little more helpful: when the upload itself arrives but the step that creates resized copies fails, you may instead see a longer message saying post-processing of the image failed, that the server may be busy or short of resources, and suggesting you upload a smaller image. Both point to the same family of problems.

Sometimes the file does appear in the library afterwards, but as a grey placeholder with no preview, or with only the original and none of the thumbnails. That half-finished state is a useful clue. It means the file reached the server and broke during resizing, not during transfer.

What is actually happening behind the progress bar

An image upload is two jobs, not one. First the browser sends the file to wp-admin/async-upload.php. Then PHP opens that image in memory and writes out every size your site needs: thumbnail, medium, large, and whatever extra sizes your theme and plugins have registered. A single photo can turn into eight or ten files.

The second job is the heavy one. A phone photo that is a few megabytes on disk can need far more memory once it is decoded into raw pixels. If PHP runs out of memory, hits a time limit, or the image library crashes, the server returns an error page instead of the small piece of data WordPress was waiting for. WordPress cannot read it, so it shows “HTTP error.”

Causes, most likely first

1. The image is very large in pixels

Not megabytes, pixels. A 6000-pixel-wide photo straight from a modern camera or phone is the most common trigger. Since version 5.3, WordPress scales down anything wider or taller than 2560 pixels and keeps the original separately (you will see -scaled in the file name), but it still has to open the full image to do that.

2. PHP memory is too low for image work

Hosting plans differ a lot here. Image processing in the dashboard uses the admin memory limit, which WordPress controls with the WP_MAX_MEMORY_LIMIT constant, but your host can set a lower ceiling that WordPress is not allowed to go above.

3. The image library on the server

WordPress uses one of two PHP extensions to resize images: Imagick (ImageMagick) or GD. It prefers Imagick when it is available. On some shared servers Imagick is installed with tight resource limits, and it fails on files that GD would handle without complaint.

4. A plugin that hooks into uploads

Image optimisation, watermarking, WebP conversion and offload-to-cloud plugins all do extra work at the moment of upload. If one of them errors out or calls an outside service that is slow, the whole upload fails with it.

5. A security rule blocking the request

Server firewalls such as ModSecurity, or a security plugin, can sometimes mistake an upload for an attack, especially if the file name contains odd characters or the image carries a lot of embedded data.

6. Your login session expired

If the dashboard has been open in a tab for hours, the security token behind the upload can go stale. This one is easy to rule out, so it goes first in the fixes below.

Fixes, from safest to most involved

The first five steps change nothing on the server. Before you move past them and start editing files, make a fresh backup of the site so you have a way back.

  1. Reload and retry. Refresh the Media page, or log out and back in, then upload the same file again. A temporary server hiccup or an expired session clears this way more often than you would expect.
  2. Try a different browser or a private window. This rules out a browser extension interfering with the request.
  3. Resize the image before uploading. Bring it down to around 2000 to 2500 pixels on the long side with any image editor and upload again. If the smaller version works, you have confirmed it is a resource problem, not a broken site. For everyday uploads this is good practice anyway, as explained in our piece on getting image weight down before it reaches the site.
  4. Rename the file. Use plain lowercase letters, numbers and hyphens. Remove apostrophes, accented letters, brackets and spaces.
  5. Look at Site Health. Go to Tools, then Site Health, then the Info tab, and open the Media Handling section. It shows which image editor is active and the version of ImageMagick or GD. Open the Server section to see the PHP memory limit and upload limits.
  6. Deactivate upload-related plugins one at a time. Start with image optimisation and WebP plugins. Retry the upload after each one. If the error stops, that plugin or its settings are the cause. When you suspect a clash between two plugins rather than one bad plugin, our guide to tracking down plugin conflicts explains how we narrow it down.
  7. Raise the admin memory limit. Open wp-config.php and, somewhere before the “stop editing” comment near the bottom, add define( 'WP_MAX_MEMORY_LIMIT', '512M' );. If nothing changes, your host is capping memory below that, and only they can raise it. The wider memory story, including the front-end limit, is in our post on the allowed memory size exhausted error.
  8. Switch the image editor to GD. If Site Health shows Imagick as active and the error persists, a small snippet in a site-specific plugin or your child theme’s functions.php tells WordPress to try GD first: add_filter( 'wp_image_editors', function() { return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' ); } );. If uploads start working, the Imagick setup on the server is the real problem, and it is worth telling your host.
  9. Check the logs. With WP_DEBUG and WP_DEBUG_LOG turned on, PHP errors from the upload are written to wp-content/debug.log. Your hosting panel’s error log may also show a memory or timeout error at the exact minute you uploaded. Look for lines with that timestamp mentioning memory, a timeout or the image library.

What usually does not help

A few common suggestions waste time. Changing folder permissions to 777 is one. Wrong permissions on wp-content/uploads give a different message, usually saying WordPress is unable to create a directory, not “HTTP error.” Setting 777 also opens the folder to anything on the server, which is a security problem of its own.

Adding .htaccess lines copied from forums is another. On many hosts PHP does not run as an Apache module, and those lines produce a 500 error for the whole site.

Reinstalling WordPress almost never fixes this either, because the core files are rarely the cause.

When “HTTP error” is a sign of something bigger

If uploads fail for every image, even tiny ones, and the problem started on a specific day, look at what changed that day. A host moving the site to a new PHP version, a plugin update, or a server migration are the usual suspects. If the dashboard is also slow, saving posts is unreliable, or you are seeing other errors, the upload is just the first place you noticed a resource or configuration problem.

Very occasionally, failing uploads appear alongside unknown files in the uploads folder or new admin users. That is not a resizing problem, and our article on PHP files turning up in the uploads folder explains why it needs a different response.

Preventing it next time

  • Resize photos before they go anywhere near WordPress. Nobody visiting your site needs a 6000-pixel image.
  • Keep the number of image plugins small. One optimisation plugin is plenty, and two will often fight.
  • Ask your host what PHP memory limit your plan allows and whether Imagick is configured with resource limits. It is a short email and the answer saves guesswork.
  • When an update arrives for an image or media plugin, test an upload afterwards, not weeks later when you urgently need to post something.

Upload errors sit alongside a group of related media problems, such as the maximum upload size message and a library that refuses to load. The full list of WordPress errors and what each one means is in our guide to common WordPress errors.

When to hand it over

If you have worked through the safe steps and uploads still fail, the remaining causes live in server settings and plugin code, and that is where guessing can make things worse. Send us the exact message, a screenshot and roughly when it started. Our WordPress bug fixing service starts with a backup, then finds which step of the upload is failing and why, and we explain what we changed once it works.

Next in this series: WordPress Maximum Upload Size: How to Raise It Safely

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.