--- title: "Fix the \"HTTP error\" when uploading images to WordPress" url: https://wpministry.co/errors/image-upload-http-error/ description: "Making the image's smaller sizes most often ran out of memory or time. Upload a copy scaled to 2560 pixels, or read the server's real error. Your file is safe." lang: en-US --- Skip to content # How to fix the "HTTP error" when uploading images to WordPress The uploader got a failed answer from the server, or none, most often because creating the picture's smaller sizes ran out of memory or time. Upload a copy scaled to 2560 pixels, or read the server's real error and fix what it names. Your original file is untouched. By WP Ministry Published October 7, 2026 Tested on WordPress 7.1.4, PHP 8.3.36 ## In short - The message is the uploader's report that the server failed. It does not say why. - WordPress 5.2 and earlier said only "HTTP error." Today it reads "The server cannot process the image." - What counts is the picture's width and height in pixels, not the size of the file. - A copy scaled to 2560 pixels on its longer side usually goes through. - The status code of the failed request and the debug log name the real cause. - Code that makes WordPress use GD first puts large pictures under PHP's memory limit. WordPress sends an uploaded picture to the server and waits for the answer. This message means the answer was a failure or never came: a 500, 502, 503 or 504 error, a 403 or 413 refusal, or a connection that dropped. It is the uploader's report that the server failed, and it says nothing about why. WordPress 5.2 and earlier put it in two words, "HTTP error.", and the name has stuck. Nothing has been lost. The file on your computer is untouched and the site is as it was. When the server fails while creating a picture's smaller sizes, WordPress asks it up to five more times to finish, then deletes the half-made upload and shows the message. ## Which message you see - **In the Media Library and the media window an editor opens:** "The server cannot process the image. This can happen if the server is busy or does not have enough resources to complete the task. Uploading a smaller image may help. Suggested maximum size is 2560 pixels." It follows any failed answer to an image. - **On Media, Add Media File:** the same sentence after a 5xx error on an image, and "Unexpected response from the server. The file may have been uploaded successfully. Check in the Media Library or reload the page." after any other failed answer, such as a 403 or a 413. - **In the block editor:** "Media upload failed. If this is a photo or a large image, please scale it down and try again.", after a 5xx error that the retries did not cure. ## Where it goes wrong A page request passes through each of these in turn. This one comes from **PHP, the language WordPress runs on**. 1. Browser 2. DNS 3. HTTPS 4. CDN or firewall 5. Web server 6. PHP (this error comes from here) 7. WordPress 8. Database and files ## What causes it - ### The picture has more pixels than the server has memory for Common To make the smaller sizes, the server unpacks the whole picture. With the GD library that happens inside PHP's memory limit, which WordPress sets to 256 MB for image work. A JPEG of 8000 by 8000 pixels needs more than that, however small it is as a file. Fix: Read the server's real answer, or Upload a copy scaled to 2560 pixels, or Raise the memory WordPress allows for image work - ### Creating the sizes takes longer than the server allows Common PHP stops a request that runs past max_execution_time, 30 seconds by default, and a proxy in front of the server can give up sooner. A large picture on a slow or busy server runs into one or the other. Fix: Read the server's real answer, or Upload a copy scaled to 2560 pixels, or Finish a half-made upload with WP-CLI, or Ask the host what refused the upload - ### WordPress has been told to use GD although the server has ImageMagick Sometimes WordPress uses ImageMagick when the server has it, and GD otherwise. Code in a theme, a plugin or a snippet can change that order through the wp_image_editors filter. With GD first, every large picture depends on PHP's memory limit. Fix: Read the server's real answer, or See which image library is in use, and put ImageMagick first - ### A plugin that works on uploads fails Sometimes A plugin that compresses, renames or moves uploaded files does its work inside the upload request, through hooks such as wp_handle_upload. An error in it ends the request with a 500. Fix: Read the server's real answer, or Rule out a plugin - ### The page was open so long that its security token ran out Sometimes The upload carries a token that lasts between 12 and 24 hours. A page left open since yesterday sends one WordPress no longer accepts, and the answer is a 403. Fix: Read the server's real answer, or Reload the page and upload again - ### The server, or something in front of it, refuses the request Sometimes nginx answers 413 to a request larger than client_max_body_size. The ModSecurity firewall answers 413 above a body limit of its own, and refuses a request that matches one of its blocking rules, with a 403 where it is set to. A proxy answers 502 or 504 when PHP dies or takes too long. Fix: Read the server's real answer, or Ask the host what refused the upload - ### ImageMagick is stopped by a limit of its own Rare ImageMagick keeps limits on memory, disk and time that the host sets. WordPress's own code notes that when ImageMagick runs out, it does not always raise an error WordPress can catch, and the request can end with no answer at all. Fix: Read the server's real answer, or Try GD when ImageMagick is the one failing, or Ask the host what refused the upload ## How to fix it ### Read the server's real answer - Takes care - Low risk - About 15 minutes - Steps tested on WordPress 7.1.4 1. #### Step 1: Find the failed request's status code Open your browser's developer tools, choose the Network tab and upload the picture again. The failed request is `async-upload.php`, or in the block editor one whose address contains `/wp-json/wp/v2/media`. - **500:** PHP stopped. The debug log has the reason: go on to the next step. - **502, 503 or 504:** something in front of PHP gave up, or PHP's process died. The pages on the 502 (https://wpministry.co/errors/502-bad-gateway/) and 504 (https://wpministry.co/errors/504-gateway-timeout/) errors cover both. - **413:** the request is larger than the server accepts. - **403:** the page's token has run out, or a security rule refused the upload. 2. #### Step 2: Turn the debug log on Without WP-CLI, how to turn on WordPress debug mode (https://wpministry.co/blog/enable-wordpress-debug-mode/) makes the same three settings by hand in `wp-config.php`. bash Copy ``` wp config set WP_DEBUG true --raw wp config set WP_DEBUG_LOG true --raw wp config set WP_DEBUG_DISPLAY false --raw ``` 3. #### Step 3: Upload once more, then read wp-content/debug.log A line with "Allowed memory size of 268435456 bytes exhausted" and a path ending in `class-wp-image-editor-gd.php` means the GD library ran out of memory: 268435456 bytes is 256 MB. "Maximum execution time of 30 seconds exceeded" means the sizes took too long. A path through `wp-content/plugins/` names the plugin that failed. 4. #### Step 4: Turn the debug log off Delete `debug.log` when you have read it. bash Copy ``` wp config set WP_DEBUG false --raw wp config set WP_DEBUG_LOG false --raw ``` ### Upload a copy scaled to 2560 pixels - Easy - No risk - About 5 minutes - Steps tested on WordPress 7.1.4 The work of making the smaller sizes grows with the picture's width times its height, not with the size of the file. WordPress scales anything wider or taller than 2560 pixels down to that and uses the result as the picture's largest size, so a bigger original gains you nothing on the page. 1. #### Step 1: Make a copy no more than 2560 pixels on its longer side Any image program's resize or export command does it. Keep the original. 2. #### Step 2: Upload the copy If it goes through, the server ran short of memory or time on the large one. Carry on this way, or use the fixes below. ### Raise the memory WordPress allows for image work - Easy - Back up first - About 5 minutes - Steps tested on WordPress 7.1.4 Before it opens a picture, WordPress raises PHP's memory limit to `WP_MAX_MEMORY_LIMIT`, which is 256M unless you set it or the server's own limit is higher. That is the setting that counts here, not `WP_MEMORY_LIMIT`. It matters most where GD is the library in use, because GD holds the uncompressed picture in PHP's memory and ImageMagick uses less of it. 1. #### Step 1: Add the line above "That's all, stop editing" wp-config.php Copy ``` define( 'WP_MAX_MEMORY_LIMIT', '512M' ); ``` 2. #### Step 2: Upload the picture again If the log shows the same number of bytes as before, the host caps PHP's memory. The page on "Allowed memory size exhausted" (https://wpministry.co/errors/allowed-memory-size-exhausted/) covers asking the host to lift it. A plugin can set the figure for image work alone through the `image_memory_limit` filter. **To undo it:** Remove the line from wp-config.php. ### See which image library is in use, and put ImageMagick first - Takes care - Low risk - About 10 minutes - Steps tested on WordPress 7.1.4 WordPress resizes pictures with ImageMagick or with GD, and uses the first on its list that the server has: ImageMagick, then GD. 1. #### Step 1: Look at Site Health Go to Tools, then Site Health, open the Info tab and then "Media Handling". "Active editor" reads `WP_Image_Editor_Imagick` or `WP_Image_Editor_GD`. "ImageMagick version number" reads "Not available" on a server without ImageMagick: GD is then all there is, and the two fixes above are yours. If the active editor is GD although ImageMagick has a version number, something has changed the order. Go on. 2. #### Step 2: Create wp-content/mu-plugins/image-library-order.php with this in it Create the folder if it is not there. The 99 makes it run after code that was added the usual way. wp-content/mu-plugins/image-library-order.php Copy ```