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
Tested on
WordPress 7.1.3, PHP 8.3.35

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

How to fix it

Read the server's real answer

  • Takes care
  • Low risk
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

  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 and 504 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 makes the same three settings by hand in wp-config.php.

    bash
    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
    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.3

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.3

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
    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" 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.3

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
    <?php
// WordPress uses the first library on this list that the server has.
add_filter(
	'wp_image_editors',
	function () {
		return array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' );
	},
	99
);

  3. Step 3: Reload Site Health and upload again

    "Active editor" now reads WP_Image_Editor_Imagick.

  4. Step 4: Remove what changed the order

    Search the theme's functions.php and any code snippets for wp_image_editors, take that code out, then delete this file.

To undo it: Delete the file.

Try GD when ImageMagick is the one failing

  • Takes care
  • Low risk
  • About 10 minutes

  1. Step 1: Check that this is your case

    Site Health shows WP_Image_Editor_Imagick as the active editor, and the debug log is empty or names class-wp-image-editor-imagick.php.

  2. Step 2: Swap the two names

    As a test, create the file from the fix above with WP_Image_Editor_GD first, and upload again.

    wp-content/mu-plugins/image-library-order.php
    <?php
// As a test: GD first.
add_filter(
	'wp_image_editors',
	function () {
		return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
	},
	99
);

  3. Step 3: Tell the host what you found

    If the upload now works, send them the "Imagick Resource Limits" lines from Site Health and ask which limit the upload reached. If it fails with a memory error instead, GD needs the memory fix above.

To undo it: Delete the file.

Finish a half-made upload with WP-CLI

  • Takes care
  • Low risk
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

When the answer is lost on the way, as with a 502 or 504 from a proxy or a closed tab, the uploader cannot clean up. The picture can then sit in the Media Library without its smaller sizes. WP-CLI starts PHP from the command line, where PHP's own time limit is 0 by default, which means none.

  1. Step 1: Connect over SSH and go to the site's folder

    How to use WP-CLI to manage a WordPress site covers connecting and checking that WP-CLI is installed.

  2. Step 2: Create the sizes that are missing

    It goes through every image, leaves complete ones alone and ends with "Success: Regenerated" and a count.

    bash
    wp media regenerate --only-missing --yes

A picture that never arrives can go in the same way: the page on upload_max_filesize shows how to add a file with wp media import. To give the web server longer instead, see "Maximum execution time exceeded".

Rule out a plugin

  • Takes care
  • Low risk
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Note which plugins are active, then switch them all off

    How to find and fix a WordPress plugin conflict covers the same test from the Plugins screen.

    bash
    wp plugin list --status=active --field=name
wp plugin deactivate --all

  2. Step 2: Upload the picture

    If it goes through, a plugin is the cause.

  3. Step 3: Switch them back on one at a time

    Put each name from your list in place of plugin-name, and upload after each. The plugin after which the upload fails is the one. Leave it off, update it or tell its author.

    bash
    wp plugin activate plugin-name

To undo it: Activate the plugins again.

Reload the page and upload again

  • Easy
  • No risk
  • About 1 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Reload the page

    A reload gives the page a new token. If WordPress asks you to log in first, do.

  2. Step 2: Upload the picture again

    If it goes through, the old token was the cause. The page on "The link you followed has expired." explains these tokens.

Ask the host what refused the upload

  • Easy
  • No risk
  • About 15 minutes

  1. Step 1: Send what you found

    Give the time of the failed upload, its status code, the picture's size in pixels and in megabytes, and the "Media Handling" lines from Site Health.

  2. Step 2: Ask the question the status code points to

    • 413: what is the largest request the web server and its firewall accept? The page on upload_max_filesize covers PHP's own upload limits.
    • 403 on a freshly loaded page: did a security rule refuse the request to async-upload.php? The page on the 403 error has more.
    • 502, 504 or no status: was the PHP process ended for using too much memory or time, and how long does the proxy wait?

When to get help

If a 2560-pixel copy fails too, the debug log stays empty and the host says nothing is being blocked, the fault is in how the server is set up, in its image library, a proxy in front of it or a limit only the host can see. Finding it takes server access and reading server logs, and more attempts with the same file will not get you closer.

Common questions

Why does a small file fail when the upload limit is far higher?

Because the limit it reached is not on the file's size. A JPEG is compressed, and the server unpacks every pixel to resize it. A picture of 8000 by 8000 pixels can be a file of about 1 MB and still need more than 256 MB of memory under GD.

What does "Suggested maximum size is 2560 pixels" refer to?

To a threshold WordPress has had since version 5.3. A picture wider or taller than 2560 pixels is scaled down to that, and the scaled copy becomes its largest size. The original stays on the server. The big_image_size_threshold filter changes the figure.

Do HEIC, WebP and AVIF files cause this message?

Not by their format. WordPress asks its image library in advance whether it can edit them. If it cannot, a WebP or AVIF file is refused before it is sent, with "The web server cannot generate responsive image sizes for this image. Convert it to JPEG or PNG before uploading." For a HEIC file the uploader says "The server cannot process HEIC images. Convert it to JPEG before uploading."

More on this subject

Would you rather we fixed it?

Quick Fix is $49. One issue, one site, up to about an hour. No fix, no fee. 30-day warranty. It starts with a free diagnosis.

Get a free diagnosis