WordPress throws a generic "HTTP error" on image upload when something between the browser and PHP rejects the file, but the actual reason gets swallowed before it reaches you. Common causes include a low PHP memory or upload limit, a missing image-processing library after a PHP version change, or a file permissions problem on the uploads folder. Work through them in that order.
Cause 1: PHP memory or upload limits
Large images, especially unresized photos straight from a phone camera, can exceed upload_max_filesize, post_max_size, or run out of memory_limit while WordPress generates thumbnail sizes. This is the single most common cause of this error.
To check and raise the limits: open cPanel and go to Software → MultiPHP INI Editor. Switch to Editor mode and look at upload_max_filesize, post_max_size, and memory_limit. Raise them comfortably above your largest image size, then save.
Don't confuse this with the PHP Version tile in the portal. That tile only switches your PHP version (7.4 through 8.3) per domain. It has no controls for upload size or memory, those live only in MultiPHP INI Editor.
If the upload works after raising these values, that confirms the limit was the cause. If it still fails, move to the next section.
Cause 2: missing or mismatched image library after a PHP change
WordPress relies on the GD or Imagick PHP extension to process uploaded images and generate thumbnails. If you recently changed PHP versions and the new version doesn't have the same extensions enabled, uploads can fail even though the file itself is fine.
Check this in cPanel under Software → Select PHP Version (the CloudLinux PHP Selector). Confirm gd and imagick are checked for your domain's PHP version. If you're not sure whether a recent PHP switch is the trigger, test by rolling back one version in the portal's PHP Version tile and retrying the upload. If it works on the older version, an extension or plugin compatibility gap on the newer version is the cause, and you can re-enable the missing extension in PHP Selector instead of staying on the older PHP permanently.
This same PHP-mismatch pattern shows up in other WordPress errors too. If you've also seen a blank page rather than an upload failure, see fixing the WordPress white screen of death for the same rollback-and-test approach applied to a full page failure instead of a single upload.
Cause 3: uploads folder permissions
Less common, but worth checking if the first two don't fix it. WordPress needs to write to wp-content/uploads/, and if permissions were changed (for example by a migration, a backup restore, or a security plugin), the write fails silently and surfaces as this same generic HTTP error.
Open File Manager in the portal, or connect by FTP, and check the permissions on wp-content/uploads/ and its subfolders against standard WordPress convention (directories 755, files 644). If you find folders owned by a different user than your account (this can happen after a restore), correct the ownership before retrying the upload.
Quick way to narrow it down
- Try uploading a small JPEG (under 500 KB). If it works, the issue is size or memory. Go back to Cause 1.
- Try uploading the same large image again right after raising the PHP limits. If it now works, you're done.
- If small files also fail, suspect permissions or a broken image extension rather than a limit.
If none of this clears it, check whether the error is really a 5xx server response rather than a WordPress-specific message. The HTTP status codes guide explains how to tell a server-level failure from an application-level one, which points you at a different fix.
When to contact support
If you've raised the PHP limits, confirmed gd or imagick is enabled, and checked permissions, and the upload still fails, open a ticket from the portal under Support. Include the exact error text, the file size and type you're uploading, and which of the steps above you've already tried. A real person will look at the server-side logs, which can show causes that aren't visible from wp-admin.