Fix a blocked WordPress image by identifying where the request fails before changing content. Open the image’s direct URL, note its HTTP response, inspect the browser Console, then check HTTPS settings, upload permissions, image processing limits, caches, and security rules in that order. A 403 points to access control, a 404 to a missing or wrong path, an HTTPS warning to mixed content or certificates, and a server error to hosting or processing.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Start with the response, not the editor
A broken thumbnail in the Media Library or a blank image on a page is only a symptom. The fastest diagnosis is to test one affected file independently.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Copy the image URL. In the editor or page source, copy the value in
srcor one of the URLs insrcset. If the image is in the Media Library, open its attachment details and copy the file URL. - Open the URL in a new browser tab. Record exactly what appears: the image, a 403/404/429 response, an HTTPS or certificate warning, a 5xx server error, a redirect loop, or a completely different file.
- Compare a working file. Test another image from the same site and directory. If every file fails, suspect the domain, uploads directory, server, CDN, or security policy. If only one file fails, suspect its path, format, name, corruption, or dimensions.
- Use a private window or a second network. This separates a local browser cache, extension, DNS, or network filter from a site-wide failure.
| What you see at the direct URL | Most likely location of the block | First action |
|---|---|---|
| The image loads normally | Page markup, srcset, lazy-loading, cache, or browser policy |
Inspect the affected page’s Console and the exact URL the browser requested. |
| 403 Forbidden | Web server, WAF, hotlink protection, permissions, or source host | Check access rules and whether the request has the correct host and referrer. |
| 404 Not Found | Wrong path, renamed file, deleted upload, or stale database/CDN URL | Locate the file in wp-content/uploads and replace the broken reference. |
| 429 Too Many Requests | Rate limiting at the host, CDN, WAF, or source host | Wait for the limit to clear, then review rate-limit and bot rules. |
| HTTPS, certificate, or mixed-content warning | HTTP image requested by an HTTPS page, or an invalid certificate | Replace HTTP references and make the site and asset hostname consistently HTTPS. |
| 500, 502, 503, timeout, or connection reset | PHP, image processing, server resources, upstream host, or CDN | Check server logs and resource limits; ask the host to trace the request. |
Read the browser evidence
On the affected page, open Developer Tools (usually F12 or the browser menu’s More tools option), then review both Console and Issues. Reload with DevTools open so the failed request is captured.
- A mixed-content message names an
http://image requested by anhttps://page. Browsers can block insecure content or upgrade some requests automatically; an automatic upgrade still fails if the HTTPS endpoint does not exist. - A certificate error identifies a hostname, certificate, or chain problem. Do not bypass it for visitors; correct the certificate or use the valid asset hostname.
- A 403, 404, or 429 in the Network panel confirms that the server or intermediary rejected the request. The Console alone may only report that the image failed.
- A CORS or CSP message indicates a browser security policy. The source host must permit the required origin, or the policy must permit the image; adding random browser extensions does not fix a public site.
- If the Network panel shows a successful image response but nothing is visible, inspect CSS, dimensions, overlays, the selected
srcsetcandidate, and lazy-loading behavior.
Confirm the WordPress URLs and every generated image URL
WordPress stores the site’s canonical addresses and uses them when generating attachment links and responsive srcset values. Go to Settings > General and verify that WordPress Address (URL) and Site Address (URL) use the intended hostname and scheme. If the site has moved to HTTPS, both normally need the HTTPS version, including the correct subdomain.
Do not stop at those two fields. View the affected page’s source and inspect all candidates in srcset, not only the visible src. Look for:
- an old
http://scheme; - a previous domain, staging hostname, or
www/non-wwwmismatch; - a CDN hostname whose certificate, path, or access rule is wrong;
- an uploads path that differs from the actual file location; and
- a thumbnail filename or size that was never generated.
Back up the database before changing stored URLs. Replace stale references with a search-and-replace method that understands serialized WordPress data, or have the host perform it. A plain text replacement can corrupt serialized settings. Afterward, clear page and CDN caches and check a fresh source view; an old cached HTML document can continue to emit the former URL.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →WordPress Site Health exposes HTTPS status and related configuration information. Open Tools > Site Health and address any HTTPS recommendation before treating individual images as content errors.
Repair mixed-content images after an HTTPS move
Mixed content is the common case in which the page is secure but an image still points to HTTP. The browser is protecting visitors, not WordPress malfunctioning.
Rank #2
- Confirm that the image’s hostname serves the file over HTTPS without a certificate warning.
- Set both WordPress URLs in Settings > General to the final HTTPS hostname.
- Search post content, widget settings, theme options, custom fields, and menus for the old HTTP image URL. Update only references belonging to this site or a CDN you control.
- Check responsive markup. WordPress may have retained an HTTP URL in one
srcsetcandidate even when the mainsrcis correct. - Purge page, object, browser, and CDN caches, then reload in a private window.
- Check redirects. A single HTTP-to-HTTPS redirect is generally preferable to a chain involving several hostnames or paths.
Do not “fix” the warning by disabling browser security. If an external image host does not provide a valid HTTPS copy, obtain a permitted local copy or choose a source that does.
Make the uploads directory writable and publicly reachable
Local media normally resides under wp-content/uploads, often in year-and-month subdirectories. WordPress needs to write the original and generated sizes, while the web server must be able to read them at their public URL. The WordPress Hosting Handbook notes that the uploads directory must be web-accessible for uploaded assets to load in a browser.
Open Tools > Site Health > Info and review the Media handling, Filesystem Permissions, and server sections. Record the upload path, maximum upload size, maximum post size, PHP version, active image editor (GD or Imagick), and any permission warning.
- If new uploads fail but older images work, the directory or its monthly subdirectory may not be writable.
- If files exist on disk but direct URLs return 403, a server rule, ownership mismatch, hotlink rule, or WAF is blocking reads.
- If files are not present at all, the upload request may have exceeded PHP or server limits, or image processing may have failed before the file was saved.
- If the URL contains the wrong directory, verify the configured uploads location and any constant or filter that changes it.
Permissions vary by host and operating system, so do not apply a blanket command without checking ownership. A common Unix baseline is directories readable and executable by the web server (often 755) and files readable by it (often 644), but the host’s documented policy takes precedence. The web-server account must own the files or have the required group access. Ask hosting support to correct ownership, permissions, and web access when you do not have shell or control-panel access.
Rank #3
Check external images and ownership
An image inserted from another website is not stored in your Media Library. It can disappear when the source owner moves, deletes, renames, privatizes, or rate-limits the file. WordPress’s Image block documentation warns that an externally inserted image may stop displaying when the original is moved, deleted, or no longer shared.
Open the direct external URL and identify its response. A 403 may be deliberate hotlink protection, while a 404 means the source no longer has that path. A 429 can be a temporary rate limit. If you have permission to use the image, select the block and choose Upload to Media Library, or download and upload an authorized copy yourself. Confirm that the resulting attachment URL is on your own HTTPS domain and that its licensing and attribution requirements are preserved.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Do not copy images merely to evade a source host’s access controls. If you do not have reuse permission, request a replacement or remove the reference.
Fix format, dimensions, corruption, and processing failures
When only particular files fail, test the file itself before changing URLs. WordPress’s media pipeline depends on the format being supported by the installed PHP image editor, a valid file signature, available memory, and browser capabilities.
Unsupported or damaged files
- Open the original file locally. If an image editor cannot decode it, export a fresh copy from the original source.
- Check that the filename extension matches the actual format. Renaming a file from one extension to another does not convert it.
- Try a conventional JPEG or PNG test image. If that works while a newer format fails, check the WordPress, PHP, GD, and Imagick versions on the site before converting the production files.
Size, dimensions, and memory
Very large pixel dimensions can exhaust PHP or device memory even when the file’s compressed size looks modest. Compare the failing file with the host’s maximum upload and post sizes shown in Site Health. Image editing can require several times the compressed file size in working memory. Have the host raise appropriate PHP memory and upload limits only after confirming available server resources; increasing limits blindly can make a busy site unstable.
Server-side editors
In Tools > Site Health > Info, note whether GD or Imagick is active. A missing or misconfigured editor can allow the original upload but prevent thumbnails and responsive sizes from being created. Ask the host to repair the extension, its security policy, or its temporary directory rather than repeatedly re-uploading the same file.
Browser capability
A browser may display an original but fail to decode a selected modern format or an unusually large image. Test the direct URL in a current second browser and inspect which srcset candidate was selected. This distinguishes a browser limitation from a missing server file.
Rule out plugins, themes, caches, and security layers
A conflict can alter image URLs, add restrictive headers, prevent thumbnail generation, or serve stale HTML. Test in a controlled order so the result is meaningful.
Best Value
- Record the current active theme and plugins, and make a backup.
- Temporarily switch to a default WordPress theme and disable nonessential plugins, especially image, optimization, security, CDN, and cache components.
- Clear the site’s page cache, object cache, CDN cache, and your browser cache.
- Test the same direct URL and page again. If the image returns, re-enable components one at a time until the failure returns.
- Inspect the component that reintroduced the failure for URL rewriting, WebP/AVIF substitution, lazy-loading markup, restrictive headers, or an exclusion list for the uploads directory.
Ask the host to review WAF events, hotlink protection, rate limits, rewrite rules, and error logs for the exact timestamp and image path. Security rules may block an image request based on its referrer, query string, user agent, or request frequency. Do not permanently disable the WAF; create the narrowest verified exception.
Treat lazy-loading as a targeted test
WordPress has used native lazy-loading by default since version 5.5. Lazy-loading delays below-the-fold requests; it does not turn a server-side 403 or 404 into a successful response. It can, however, expose theme JavaScript, intersection-observer, or markup problems.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchFor one above-the-fold image, temporarily force eager loading by adding loading="eager" to the rendered image or by using the theme or block setting that controls loading. Clear caches and test again. If eager loading works, inspect the lazy-loading implementation and restore deferred loading for images that are not immediately visible. Do not remove lazy-loading globally as a first response to a missing file.
Use the failure pattern to choose the fix
| Pattern | Likely layer | Evidence to collect | Reversible fix to try |
|---|---|---|---|
| All local images fail on every page | Domain, HTTPS, uploads access, server, or CDN | Direct URL status, Site Health HTTPS and filesystem details | Correct canonical URLs, permissions, certificate, or access rule. |
| Only images after an HTTPS migration fail | Stored HTTP URLs or invalid HTTPS endpoint | Console mixed-content message and srcset values |
Back up, update stored URLs safely, then purge caches. |
| Only newly uploaded images fail | Write permissions, ownership, PHP limits, or processing | Upload error, upload/post limits, GD/Imagick status | Fix filesystem access or host limits; test a small known-good file. |
| Original loads but thumbnails are broken | Thumbnail generation, memory, image editor, or stale cache | Which size URL fails and server error log | Repair GD/Imagick or resources, then regenerate sizes using a trusted method. |
| Only external images fail | Source host, hotlink policy, deletion, or permission | External response status and ownership permission | Use an authorized local Media Library copy or a functioning source. |
| Works with plugins disabled | Plugin, theme, optimization, or security conflict | First component re-enabled when failure returns | Update, reconfigure, replace, or isolate that component. |
| Works in one browser but not another | Format support, CSP/CORS, extension, or cached policy | Console policy error and selected image format | Correct headers or provide a broadly supported format. |
Recovery checklist before escalating
- Save one failing URL, its status code, timestamp, and a working comparison URL.
- Capture the relevant Console, Issues, and Network messages without including private tokens.
- Confirm both WordPress URLs, the certificate, redirects, and every
srcsethostname. - Check Tools > Site Health > Info for upload paths, limits, PHP details, image editor, and filesystem permissions.
- Verify that
wp-content/uploadsand its subdirectories are both writable by WordPress and readable over the web. - Test a small standard image and a failing image to separate processing from delivery.
- Clear relevant caches only after correcting the underlying URL or server rule.
- Test with a default theme and nonessential plugins disabled, then re-enable them individually.
- Ask the host for WAF, rate-limit, rewrite, SSL, and error-log review when the response is generated outside WordPress.
This sequence keeps the diagnosis reversible: first observe the response, then correct the layer that produced it. Editing the post or repeatedly re-uploading files cannot repair a certificate, a forbidden path, a stale CDN object, or an unwritable uploads directory.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




