HTTP error when uploading images
The file transferred, then something failed while WordPress was generating the thumbnails. The message is the same whatever that something was.
HTTP error.
The upload itself worked; the failure is in post-processing. Try the same image at a smaller pixel size — if that succeeds, the cause is memory or the image library rather than anything to do with the network or the file type.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| The resize runs out of memory | Large-dimension images fail while small ones of the same format succeed. Pixel count matters here, not file size: a 6000×4000 PNG needs far more memory than its megabytes suggest. | Raise memory_limit for the request. An uncompressed bitmap of width × height × 4 bytes has to fit in memory before anything is written back out. |
| ImageMagick is missing, broken, or resource-capped | Site Health lists no image-processing module, or ImageMagick's own policy.xml caps memory and area below what the image needs. | Install or repair the Imagick extension, or raise the limits in ImageMagick's policy.xml. Forcing WordPress to use GD instead is the quick workaround when neither is possible. |
| A security rule rejects the request | The upload fails instantly rather than after a pause, and the web server or WAF log records a rejection at the moment you clicked. | Find the triggering rule and exempt async-upload.php for authenticated editors. ModSecurity's default rule set is the usual source on cPanel-style stacks. |
| The request times out mid-resize | The browser waits a long time and then reports the error, and the PHP log shows the request was killed rather than finishing. | Raise max_execution_time for admin requests, or upload a smaller image. Several thumbnail sizes are generated in one request, so the work is the sum of all of them. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Confirm it is post-processing, not transfer
Scale the same image down and try again. A success at smaller dimensions rules out the network, permissions and the file type in one test.
Check which image library PHP actually has
WordPress prefers Imagick and falls back to GD. Knowing which one is in play decides where to look next.
php -r 'var_dump(extension_loaded("imagick"), extension_loaded("gd"));'Read ImageMagick's own limits
These are separate from PHP's and are frequently the real ceiling on shared stacks.
identify -list resource
Force GD if Imagick is the problem
A drop-in filter switches the editor implementation without touching the server, which is enough to confirm the diagnosis.
add_filter( 'wp_image_editors', function () { return [ 'WP_Image_Editor_GD' ]; } );Watch the log while you retry
Upload once with the log open. A fatal from the image library and a rejection from a WAF look nothing alike, and this is where they become distinguishable.
tail -f wp-content/debug.log
What the platform takes off the list.
Both image libraries are present and their resource limits are set against the plan's memory rather than left at a distribution default, so a large photograph resizes instead of dying halfway. PHP limits for admin requests are raised separately from front-end ones, because generating six thumbnail sizes is not the same shape of work as serving a page.
Questions, answered.
Why does the same image upload fine on my laptop?
Does converting to WebP or JPEG before uploading help?
Is this the same as the file type not being permitted?
The error is intermittent on the same file. What does that mean?
If that was not it.
These fail in ways that look similar from the browser.