WordPress says an image upload failed, but the picture appears in Media Library. Before clicking Upload again, open that item. The original file may have arrived while WordPress failed to create the smaller versions your theme needs. Retrying blindly can leave duplicate attachments without fixing the missing sizes.
This guide is for an ordinary site owner seeing an “HTTP error,” “server cannot process the image,” or a similar upload failure. The message alone does not identify the cause. First establish what saved, then decide whether the problem is the file transfer, image processing, or the public page.
First, check whether the image actually saved
- Keep the original image on your computer. Do not delete or overwrite it.
- Refresh Media > Library once and search for the file name. Check for duplicates before retrying.
- Open the attachment details. Record the file name, dimensions, file URL, and the exact error message. Do not publish a private image merely to test it.
- If the item exists, open its file URL in a new tab. Then inspect one page that uses it at desktop and mobile sizes. A visible original does not prove that thumbnails, responsive sizes, or a CDN copy exist.
WordPress’s Media Library documentation explains where to see an attachment’s file type, size, dimensions and URL. The Add New screen also displays the host-set maximum upload size. Those two screens give a safer starting point than changing server limits based on a vague error.
Which stage failed?
Use this table as a diagnostic order, not as a claim that every error has one cause.
| What you can observe | Likely stage to investigate | Safe next check |
|---|---|---|
| No new item appears in Media Library. | The file may not have reached WordPress or passed its upload checks. | Try one small, ordinary JPEG through Media > Add New. Compare its size with the displayed limit. Note whether the same file works in another browser. |
| The attachment exists, but its preview or smaller sizes are missing. | Saving the original and processing derivatives are separate steps. | Keep the item; compare the original URL with a page’s actual image URLs. Give support the exact attachment and error rather than bulk-regenerating everything. |
| The library looks complete, but the site shows a broken image. | Delivery, a template, CDN or cache may be serving a different URL. | Open the image URL from the rendered page and compare it with the attachment’s URL. Check one clean browser session before purging the whole site. |
| Only one file type or one large image fails. | Format support, file contents, processing resources or the upload limit may differ. | Test a small known-good JPEG. Preserve the failing original for diagnosis; do not assume that increasing every limit will solve it. |
The WordPress upload handler can reject a file for reasons such as a size limit, a missing temporary folder, a failed disk write, or a disallowed type. Those are different failures with different owners; the core upload handler documents the checks. The generic “HTTP error” label cannot tell you which one occurred.
Why the original can exist while the page is still broken
A page rarely displays only the original file. WordPress, themes and plugins can prepare several image sizes for cards, heroes, galleries and mobile layouts. A server may save the source, then fail while making those sizes or finalizing metadata. In that state, the Media Library may show an attachment even though a page requests a missing derivative.
WordPress has documented upload and post-processing as separate requests. WordPress 7.1 also introduced a browser-side processing path with a server fallback on supported setups. Our WordPress 7.1 media-processing guide covers testing both paths and their integrations. An upload error on a current site does not, by itself, prove that the new path is responsible.
A safe five-minute comparison
Use two files: the failing original and one small known-good JPEG you are allowed to upload. Work on staging if the site has customer media, a CDN/offload integration, or a critical product gallery.
- Record the time, browser, file type and size, WordPress message, and whether the attachment appears.
- Try the known-good file once. If it also fails, the problem is less likely to be unique to your original image.
- If the library item exists, compare its file URL with the URL used by the page’s broken image. Do not infer success from a thumbnail in the admin alone.
- Check Tools > Site Health > Info for the upload limit and media-handling information. Share relevant findings with the host or developer, not a public screenshot of the full dashboard.
- Stop repeating uploads if you see duplicate attachments, missing public sizes, errors on all files, or a live gallery changing unexpectedly.
WordPress’s Site Health guide describes the upload-size and file-upload checks. It does not replace server or browser logs, but it helps separate a basic limit from a later processing or delivery problem.
What to send to the person fixing it
| Include | Why it helps | Keep private |
|---|---|---|
| Exact error wording, timestamp, browser and affected attachment ID or file name. | Lets support correlate the attempt with the right request and server log. | Do not send admin passwords, API keys or a login link. |
| Whether the original URL opens, whether a smaller page image fails, and whether a known-good JPEG works. | Separates transfer, processing and delivery. | Do not share a private customer image publicly. |
| Recent changes to the host, security rules, image plugin, CDN or WordPress version. | Provides a bounded timeline without treating correlation as proof. | Do not disable a firewall or loosen file permissions as a blind test. |
If several files fail or required sizes are missing, a developer or host should inspect the failed upload request and matching logs, then test one reversible fix on staging. Webless can trace the file from the upload request through image processing, template output and CDN delivery. That is different from selling a blanket plugin or increasing PHP limits without evidence.
Do not use a broad fix for an unknown stage
A small-file test is reasonable. Changing live file permissions recursively, disabling security checks, switching image libraries globally, or regenerating every thumbnail is not a first step. Those actions can affect the whole media library and may hide the original failure. Take a backup and define a rollback before a developer changes the pipeline.
Once one controlled upload succeeds, verify the actual public image at desktop and mobile sizes. The job is complete only when the required file variants exist, the page uses them, and the original failed case works again. If the file appears in the library but a page still breaks, the diagnosis is not finished.