An image can disappear in several very different ways. The original file may be missing, WordPress may have failed to create a smaller version, the post may not have a featured image assigned, or the Media Library itself may not be loading.
Look at where the image fails before replacing files or regenerating every thumbnail. If the full-size image opens but a small preview does not, you already know the original upload survived and can focus on the generated size or template that requested it.
Follow the matching check before uploading duplicates or regenerating every image. The exact file requested by the browser is the most useful clue.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Identify which image version is actually missing
| What is missing | Check first | Next action |
|---|---|---|
| Featured image on one post | Post image assignment | Compare post and archive templates |
| Thumbnail, original opens | Requested resized file | Test regeneration on a small backed-up selection |
| Image after migration | Actual requested domain and path | Correct the setting generating the old address |
| Image on mobile only | Responsive candidate chosen by the browser | Compare the failing file with desktop |
| Media Library grid | List view and failed admin request | Inspect REST/AJAX and scripts before assuming file loss |
Is the image missing from the post or only its preview card?
- Open the affected post and check its featured-image assignment.
- Preview the full post, blog card and category archive.
- Compare another post using the same template.
- If the assignment is correct, inspect whether the template includes the featured image.
A featured image needs both an assignment to the post and a theme or template that displays it. Look at the post’s featured-image setting first. If the expected image is there, compare the public post with the blog or category archive where it is missing.
Those views can use different templates and image sizes. A picture that appears on the full post but not on the archive may point to the archive layout or its requested thumbnail. Theme settings and, in block themes, template blocks can also control whether an image appears at all.
Re-uploading the original cannot make a template display a featured image it deliberately omits. A comparison with another post using the same layout is often more revealing.
The address requested by the browser matters
- On the public page, use the browser’s Open image in new tab command for the broken image when available.
- Compare its domain and file path with the original in the Media Library.
- If necessary, use Developer Tools → Network to identify the exact image request.
- Record whether it returns 404, 403, a certificate failure or a valid image.
For a broken image on a public page, open the actual image address in a new tab. Notice whether it belongs to the current domain, an old staging site or a CDN. A missing-file response, an access-denied response and a certificate problem provide different clues.
After a migration, content or plugin settings may still refer to the old domain. An image optimization service may also point to a cached or transformed copy. Correcting the place that generates the address is preferable to repeatedly replacing the image in individual posts.
If the page uses HTTPS but an asset is requested over HTTP, inspect the browser’s security or Console message. The relevant issue may be the resource address rather than the image data.
Why the original works while a smaller copy fails
Illustrative example: photo.jpg opens while photo-300x200.jpg returns 404. This suggests checking that generated size. It does not establish that the original is missing, and replacing every image URL would be premature.
WordPress creates resized versions of uploaded images, and themes or plugins can request additional sizes. A page can therefore ask for a file that is different from the original you see in the Media Library.
Suppose the original image opens, but the URL containing a size suffix returns 404. That makes a missing resized file a useful possibility to investigate. A change to registered dimensions does not automatically recreate every older image at those dimensions.
Regenerating sizes can help when the required files are missing or the size configuration has changed. Keep the original media backed up and test a small selection first. Bulk regeneration is not the right starting point when the actual problem is a wrong domain or a template setting.
Different devices can choose different image files
Responsive image markup lets the browser choose among several files through attributes such as srcset and sizes. This normally improves delivery, but a missing candidate can make an image fail on one screen while it works on another.
In the browser’s Network panel, look at the image file actually requested on the affected device or viewport. Comparing that address with the working version is more useful than assuming that mobile styling is responsible.
When the Media Library grid stays empty
The Media Library is an administration interface, so it can be interrupted by a script error or failed REST or AJAX request. If the grid remains blank, compare its list view where available and inspect the Console and Network panels.
Files found in the uploads directory are not, by themselves, proof that the corresponding attachment records are intact. Equally, an empty grid is not proof that every file has been deleted. A recent media, security or administration plugin change may explain a failed request without involving the files themselves.
Changing file permissions at random can create another problem. If a server response or log identifies a permission or storage issue, the host can help correct that specific path and configuration.
Confirming the image is available again
After the correction, open the affected post and archive while logged out. Check the device size that originally failed, then confirm the Media Library can still display and select the attachment. Refresh the relevant delivery cache if it contains an older response.
The useful result is more than one restored picture: the original, required resized files and intended templates should agree. Keeping a note of which file or request failed makes future media problems much easier to recognize.
Official image documentation and related checks
- WordPress Theme Handbook: Featured Images and Post Thumbnails
- WordPress Developer Reference: set_post_thumbnail_size()
- WordPress Common APIs Handbook: Responsive Images
- WordPress content not showing: embeds, widgets and output layers
- WordPress upload and file error troubleshooting
A small verification set
Check one original file, its required thumbnail, the full post and archive card, and the device size that originally failed. Confirm the attachment remains selectable in the Media Library. Keep the same set for a future theme or media-plugin update so a visual regression is easier to locate.