When WordPress images are not loading (broken icons, empty boxes, or missing thumbnails), the Media Library upload often already succeeded. The failure is usually on the serving or rendering side: a wrong URL after a migration or SSL change, hotlink protection, a CDN or offload mismatch, a lazy-load plugin conflict, or intermediate sizes that were never generated.
Work this checklist in order. Prefer staging when you can reproduce the broken image there. Take a backup before bulk URL replaces, regenerating every thumbnail, or changing CDN and security rules on production. This article is about images that fail to display after they should already be in the library. If the uploader shows an HTTP error, a spinning library, or files that never finish uploading, use media upload errors. If WordPress reports “Failed to write file to disk,” use failed to write file to disk. If the browser warns about mixed content or “Not secure” while images request http:// on an HTTPS page, also see mixed content and SSL errors. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what failed
- Note whether one image fails, every image fails, or only thumbnails / featured images fail while full-size opens.
- On the broken page, use the Network panel to record the image URL actually requested and its HTTP status. Check the Console for blocked requests. Open that URL separately only as a comparison.
- Confirm the file still appears in Media → Library. If uploads fail or the library never finishes loading, stop and use media upload errors.
- If the site is offline or returns host errors, use site down first.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Image URL 404; file missing on disk | Path / migration / offload | Compare attachment URL to the real file under wp-content/uploads or the offload bucket |
| Image URL 404; file exists on disk | Wrong base URL or rewrite | Site Address / WordPress Address; CDN origin path; permalink or uploads rewrite |
| Image URL 403 or hotlink / referrer denial | Hotlink protection / WAF | Host or CDN hotlink rules; allow your own hostname |
HTTPS page; console blocks http:// image | Mixed content | Mixed content checklist |
| Full image OK; thumbnails broken or gray | Missing intermediate sizes | Regenerate thumbnails for that attachment; confirm GD/Imagick |
| Started after a lazy-load or optimization plugin | Front-end script conflict | Disable that plugin on staging; retest the same URL |
| Upload fails with write-to-disk or HTTP error | Upload path | Write-to-disk or media upload |
Safe diagnostic order
- Inspect the image request on the broken page. Open the browser’s Network panel, reload the page, and record the image URL actually requested and its status. Responsive images may load a
srcset candidate rather than the src value, and lazy loading may change the URL. Check the Console for mixed-content or script errors. Then open the requested image URL separately as a comparison. A direct-tab result can differ because cookies or referrer headers change; it does not by itself prove how the image loads inside the page. Ask your host to inspect a 403 rather than assuming hotlink protection is the cause. If the console shows a mixed-content block for an HTTP image on an HTTPS page, use mixed content and SSL errors.
- Confirm the file exists where WordPress thinks it is. In Media Library, open the attachment details and note the File URL. On the host (or in the offload/CDN console), confirm that object exists. If the library row exists but the file is gone, restore from backup or re-upload that one file before regenerating the whole site.
- Check URLs after a migration or HTTPS change. Ask your host to confirm the correct Site Address (
home) and WordPress Address (siteurl), including any subdirectory. These two values can legitimately differ, so do not set both to the public hostname just to fix an image. If stored image URLs still point to an old domain or HTTP address, back up and test a WordPress-aware search-replace on staging using the confirmed old and new URLs. Avoid editing serialized data by hand. Purge page and CDN caches, then retest the affected page.
- Check CDN and media-offload sync. If you use a CDN or S3/Cloudinary-style offload, confirm the public URL the page requests matches the synced object, and purge that URL at the CDN. A local file with a CDN URL that was never uploaded (or the reverse) looks like “broken images” even when uploads once worked.
- Relax hotlink protection for your own site. Host or CDN hotlink rules that require a specific referrer can return 403 when images are opened directly, loaded from a new domain, or requested by email clients and PageSpeed tools. Allow your production hostname (and
www / apex if both are used). Retest the image URL after the rule change.
- Test lazy-load and image-optimization plugins on staging. Temporarily disable the lazy-load, WebP, or “smush” plugin that changed last, purge caches, and reload the page. If images return, re-enable with safer settings (or replace the plugin) rather than leaving optimization off permanently.
- Regenerate missing thumbnails when only sizes fail. If the full-size URL works but theme thumbnails or srcset sizes 404, regenerate intermediate sizes for the affected media (a thumbnail regeneration tool or host-approved method). Confirm the host provides GD or Imagick. Do not mass-regenerate on production until a single test attachment succeeds on staging.
- Retest the public page. Reload the post or page in a private window, confirm the image and a typical thumbnail, restore temporary plugin changes, and keep the durable URL, CDN, or hotlink fix that resolved the break.
Common causes
- Hardcoded old domain or
http:// image URLs after migration or SSL.
- CDN or offload plugin URL rewrite out of sync with the real file.
- Hotlink protection or WAF rules returning 403 for image requests.
- Lazy-load or image-optimization plugins breaking
src / srcset in the theme.
- Missing intermediate thumbnail sizes after a theme or size-setting change.
- Confusing display failures with upload failures or “Failed to write file to disk.”
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site where images fail to display on a specific public URL or set of URLs: confirming the image HTTP status, fixing wrong or mixed-content URLs, coordinating CDN/hotlink repairs, resolving a lazy-load conflict, or regenerating missing thumbnails for the affected media. Paste the public page URL, one broken image URL, the HTTP status if you have it, and when it started. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full redesigns, new galleries, site-wide stock-photo replacement, and upload failures that never create a Media Library item are outside this offer. Use media upload errors for upload/processing failures and failed to write file to disk for filesystem write errors.
Related checks
If the same image URL still fails after a confirmed file on disk, correct public URL, CDN purge, hotlink allowlist, and a staging plugin test, send your host the page URL, image URL, HTTP status, and the start time. Suspected compromise needs a security investigation as well as restoring image delivery.