“HTTP error” in the WordPress Media Library is a vague message. It might appear before the file reaches the server or while WordPress is creating image sizes afterward. The useful question is not “Which of ten fixes should I paste into my site?” It is “Which step failed?” Start with a small comparison upload and the exact response, then change one thing at a time.
Do these three checks first
- Try a small JPEG or PNG with a simple filename, such as test-image.jpg. Then try the file that failed. If only one file fails, the file itself or image processing deserves attention.
- Try the same file in Media > Add New and, if relevant, from the editor. Refresh the Media Library after a failed attempt. Sometimes the original uploaded but thumbnail generation did not finish, and repeated uploads only create duplicates.
- Note whether the error affects one browser, one user account, or every upload. Record the approximate time and file size before asking your host for logs.
Do not keep retrying a large upload without checking the Media Library. A partially successful request can leave the original file there even though the screen shows an error.
Use the symptom to narrow the cause
| Symptom | Likely area to investigate |
|---|---|
| Only one image fails | File format, damaged file, dimensions, metadata, or image processing. Export a clean copy and compare. |
| Large files fail but small ones work | Effective upload-size limit, request-body limit, available disk space, or processing resources. |
| All uploads fail for all users | File permissions, server or firewall response, PHP configuration, or a failing plugin. |
| Original appears but thumbnails do not | Image editor or resource failure during sub-size generation. |
| One browser fails | Extension, session, network, or browser-specific issue. Test a private window or another browser. |
Check WordPress Site Health and your host limits
Open Tools > Site Health > Info and expand Media Handling and Server. WordPress shows the active image editor, file-upload availability, maximum effective file size, and related server information there. The Site Health documentation explains those fields. Compare the effective limit with the failing file, not just the number shown by one PHP setting.
If the file is too large, resize or export it appropriately for the page, or ask your host to raise the relevant request and upload limits. Upload limits and PHP memory are not the same setting. Adding a WordPress memory constant does not automatically increase the maximum allowed upload size.
Check whether image processing is the failing step
When WordPress receives an image, it may create several sizes for the theme and plugins. If the original appears in Media Library but sizes are missing, compare a small image with the failing one and note its pixel dimensions. Ask your host to review the PHP error log and image-library errors at the upload time. Site Health identifies whether the site currently uses GD or Imagick.
Do not paste a filter into functions.php to switch image editors just because a tutorial says Imagick is always the problem. The log should point to a processing failure first. A host can help test the available image libraries on staging without risking a live theme file.
Check plugins and the actual server response
If the problem began after installing an image optimization, security, or media plugin, reproduce it on a staging copy with that plugin disabled. For a live store, do not deactivate payment, security, or checkout tools blindly. If every upload fails, ask the host for the HTTP status and web-server or WAF log entry for the upload request. A blocked request needs a targeted fix to the rule that blocked it.
Never disable ModSecurity or other firewall protection across the site, and never add a broad allow rule for upload or XML-RPC endpoints to make a file go through. The old version of this article suggested those shortcuts. They can create a security problem while leaving the actual cause unresolved.
Check file permissions and updates
WordPress needs to write to its uploads directory. Its media documentation notes that file permissions can prevent uploads. Ask the host to inspect ownership, writable directories, and disk usage; do not apply blanket world-writable permissions. If the error started after an update, check the PHP and WordPress versions and reproduce on staging before changing a live site.
When to stop troubleshooting yourself
If all uploads fail, the host logs show a server-side error, or this is a store or client site where media changes matter, send the host the failing filename, size, time, exact error text, and whether a small comparison file works. Those details are much more useful than “WordPress gives an HTTP error.”
If the site has wider errors as well, the WordPress 503 guide helps separate hosting outages from application failures. Once uploads work again, check that the image actually renders at the intended size on mobile and desktop.
This is a diagnostic sequence, not a promise that one setting fixes every upload error. Back up the site before changing production configuration, and use staging when the change affects plugins or image processing.