iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Fix blocked WordPress images by identifying where the request fails before changing content. Open the image’s direct URL, note the response (image, 403, 404, 429, HTTPS warning, or server error), then use browser developer tools and WordPress Site Health to narrow the problem to the browser, WordPress, the web server, a CDN or firewall, or the image’s original host. This order prevents you from trying plugin changes when the server is actually denying the file, or rewriting URLs when the file is simply missing.
The sections below cover images missing from pages, broken Media Library thumbnails, failed uploads, mixed-content warnings after an HTTPS move, and images that work for some visitors but not others.
Recommended Free Tools
Start by locating the block
An image can be blocked at several independent layers. The visual symptom alone is not enough to identify the cause.
| What you observe | What it usually indicates | First place to investigate |
|---|---|---|
| The direct image URL returns 403 Forbidden | The web server, CDN, WAF, hotlink rule, permissions, or source host is refusing access. | Server and security logs, file permissions, hotlink settings, and the requesting domain. |
| The direct URL returns 404 Not Found | The path or filename is wrong, the file was moved or deleted, or a rewrite rule is misrouting the request. | The URL in the page, the uploads directory, and recent media moves or migrations. |
| The URL returns 429 Too Many Requests | A rate limit is being triggered by the host, CDN, WAF, or an automated process. | Rate-limit rules, cache behavior, and whether requests come from one IP or many. |
| The URL shows an HTTPS or certificate warning | The certificate, hostname, redirect, or protocol configuration is invalid. | The exact hostname in the image URL and the site’s TLS configuration. |
| The URL displays the image, but the page does not | The browser may be blocking mixed content, a policy may block the request, or the page may contain a bad srcset candidate. |
DevTools Console and Issues panels, then the rendered HTML. |
| The Media Library thumbnail is blank or broken | WordPress cannot read the original or generated thumbnail, image processing failed, or uploads are not publicly accessible. | Site Health, the uploads directory, PHP limits, and the image editor. |
Do not begin by re-uploading every image. A new upload cannot repair a blocked hostname, a denied directory, or a browser security policy.
Run a repeatable diagnostic sequence
- Open one affected image directly. Copy the image address from the page or Media Library and open it in a new browser tab. Record the exact result: the image itself, a 403, 404, 429, HTTPS warning, redirect loop, server error, or an HTML error page masquerading as an image.
- Inspect the failed page in DevTools. Open the browser’s developer tools, then check the Console and Issues panels. Mixed-content messages identify HTTP resources requested by an HTTPS page. Browsers may block those resources or automatically upgrade some requests, so the message and the final requested URL both matter.
- Inspect the actual HTML URLs. Check the image’s
srcand every URL insrcset. Look forhttp://on an HTTPS page, an old domain, a staging hostname, a CDN domain that no longer serves the file, a wrong directory, or an incorrectly encoded filename. - Check WordPress’s canonical addresses. In Settings > General, confirm that both WordPress Address (URL) and Site Address (URL) use the intended HTTPS hostname. If the dashboard is unavailable, ask the host to verify the corresponding configuration rather than changing database values blindly.
- Review Site Health information. Go to Tools > Site Health > Info. Review the file-upload settings, maximum upload and post sizes, active image editor (GD or Imagick), PHP and server details, and filesystem information. These values reveal whether WordPress can create and serve media.
- Determine ownership. Decide whether the image is in your own
wp-content/uploadsdirectory or is loaded from another site. An external URL has a separate owner, availability policy, and access rules. - Isolate WordPress-level conflicts. Clear browser, page-cache, and CDN caches. Temporarily switch to a default theme and disable nonessential plugins, then test one image. Re-enable components one at a time so the conflicting component is identifiable.
- Check infrastructure controls. If the file exists and WordPress is configured correctly, inspect web-server rewrites, WAF and hotlink protection, CDN rules, rate limits, and directory access. Host support may be required for logs or permission changes.
Repair HTTPS and mixed-content image failures
After moving a site from HTTP to HTTPS, old image references can remain in post content, widget settings, custom fields, CSS, cached HTML, or generated responsive-image markup. An HTTPS page requesting an HTTP image is mixed content. The browser, not WordPress, may block that request before the server can deliver it.
Confirm the mismatch
In DevTools, identify the blocked request and compare the page protocol with the image protocol. Also check whether the image uses a different hostname, such as a former domain, staging site, or CDN. A page can be fully HTTPS while still emitting an insecure URL through srcset or a background-image rule.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Correct the site addresses and stored URLs
Set both WordPress URL fields to the final HTTPS address, including the correct hostname and absence or presence of www as appropriate for the site. Then locate stale HTTP values in content and settings using a backup-aware search-and-replace method or a migration tool that understands serialized WordPress data. Do not perform a raw database replacement that can corrupt serialized settings.
Clear every cache layer
After correcting URLs, purge the WordPress page cache, reverse proxy or CDN cache, and browser cache. A cached page can continue to send the old request even after the database is correct. Re-test in a private window and inspect the final HTML rather than relying only on what the editor displays.
Check the certificate and redirects
The image hostname needs a valid certificate covering that exact name. A redirect from the image URL to another hostname, an incomplete certificate chain, or a redirect loop can look like a missing image. Resolve the certificate or redirect problem at the host or CDN; changing the image block will not fix TLS.
Fix wrong paths, 404 responses, and broken thumbnails
Verify the file and filename
Compare the URL path with the actual file in wp-content/uploads, normally organized into year and month folders. Check capitalization, spaces, special characters, and the extension. Many production servers treat uppercase and lowercase filenames as different files.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallUnderstand generated image sizes
WordPress and themes commonly request resized derivatives through srcset. If the original exists but a derivative is missing, the browser may select a broken candidate at a particular viewport width. A failed image editor, interrupted migration, or deleted thumbnail can create this pattern. Regenerate the required derivatives only after confirming that the original is readable and that the server has enough memory and disk space.
Review rewrite and directory rules
Rules in the web server configuration or an uploads-directory configuration file can deny image extensions or route them to an application handler. Ask the host to compare the current rules with a known-good WordPress configuration. Avoid removing security rules wholesale; identify the specific rule that changes the response for image requests.
Make the uploads directory usable and public
WordPress uploads require two different capabilities: the PHP process must be able to write files and the web server must be able to serve them. The default location is wp-content/uploads. If either capability is missing, uploads, thumbnails, or existing media can fail independently.
Check write access
In Site Health, review filesystem and media information. An unwritable directory can allow the original upload to appear in the Media Library while preventing thumbnails, or it can fail before a file is saved. Correct ownership and permissions through the host or deployment system, using the least privilege that permits WordPress to create and update media. Do not make the entire site world-writable as a shortcut.
Rank #3
Check web access
The uploads directory must be web-accessible for browsers to load user content and uploaded assets. A restrictive directory rule, authentication requirement, or deny directive can produce 403 responses even when the file is present. The host should verify that image requests are allowed while executable files remain protected.
Check storage and PHP limits
Compare the image size with the values shown in Site Health for maximum upload and post sizes. Also consider PHP memory available during resizing, available disk space, and any server timeout. A large upload may appear to fail as a generic HTTP error while the underlying cause is a size or processing limit. Increase limits only as far as the host can support, then retry with a small known-good image to distinguish a limit problem from a path problem.
Handle external images safely
An image inserted from another site is not stored in your Media Library. It can disappear when the source owner moves or deletes the file, changes permissions, blocks hotlinking, or stops sharing it. Your WordPress settings cannot restore a file that another host no longer serves.
Test the source independently
Open the external URL directly and note its response. A 403 may be intentional hotlink protection that allows visits from the source site but denies embedding. A 404 means the source file is gone or the path changed. A 429 may indicate that the source is rate-limiting your visitors.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Create a durable local copy when permitted
If you have permission to reuse the image, use the editor’s Upload to Media Library option or download and upload the file yourself. Add appropriate attribution or licensing information. A local copy gives you control over the file, its derivatives, and its availability, but it also makes you responsible for storage, backups, and rights.
Resolve format, dimensions, and image-processing failures
When only certain formats or unusually large images fail, investigate processing rather than URLs.
- Format support: Confirm that the server’s GD or Imagick library and the browser support the format being uploaded or displayed. A format that works in a desktop editor may not be enabled on the host.
- Corruption: Open the original locally and re-save a copy. If a re-saved file works, the original encoding or metadata was damaged.
- Dimensions: Extremely large pixel dimensions can exhaust memory during thumbnail creation even when the compressed file size is modest. Resize the source or raise the available memory with host approval.
- Memory and timeouts: Image conversion can require several times the file’s compressed size in memory. Review PHP memory and execution limits when the original uploads but derivatives do not.
- Browser capability: An older browser may not decode a newer format even though WordPress stores it correctly. Test the same URL in a current browser before changing server settings.
- Content Security Policy and workers: A restrictive CSP can prevent image editors or browser workers from processing media. The Console usually identifies the blocked worker or source directive; adjust the policy narrowly rather than disabling CSP.
Investigate 403, WAF, CDN, and hotlink blocks
A 403 is an access decision, not proof that the file is absent. Compare a successful request and a failed request, including hostname, referrer, cookies, IP, and user agent where your logs make those details available.
Hotlink protection
Hotlink rules often deny requests whose referrer is not on an approved list. They can accidentally block your own domain after a domain change, or block legitimate privacy-focused browsers that omit the referrer. Update the rule to include the active site and CDN host, then test without weakening protection for unrelated file types.
WAF and security plugins
A firewall may classify image query strings, repeated requests, unusual filenames, or a migration process as suspicious. Check the security event log for the exact rule and timestamp. Allow the legitimate path or request pattern instead of turning off the entire firewall.
CDN origin and cache behavior
A CDN can cache an old 403 or point to the wrong origin path. Purge the affected object, verify the origin hostname and directory mapping, and test the origin URL separately when possible. A successful origin response with a failed CDN response indicates a delivery-layer configuration problem.
Separate plugin, theme, cache, and lazy-loading problems
Use a controlled conflict test
Back up the site, switch temporarily to a default theme, and disable nonessential plugins. Test an image in a private browser window after clearing relevant caches. If the image returns, restore components one at a time until the failure reappears. This identifies a particular optimization, security, gallery, or rewriting component instead of leaving the site in an unexplained disabled state.
Treat lazy-loading as a targeted test
WordPress has used native lazy-loading by default since version 5.5. Lazy-loading controls when a browser requests an image; it does not create a 403 or 404 and does not repair a mixed-content URL. For an above-the-fold image that remains blank, temporarily force loading="eager" while diagnosing. If that changes the result, inspect the lazy-load plugin, JavaScript observer, CSS visibility, and cache rather than leaving every image eager permanently.
What to give your host or developer
Escalation is faster when the problem is reproducible. Provide:
- The exact image URL and the page URL where it fails.
- The timestamp and HTTP status, including response headers if available.
- A screenshot or copied message from the Console or Issues panel.
- Whether the original file exists in
wp-content/uploadsand whether another image works. - The WordPress version, PHP version, active image editor, theme, and recently changed plugins or CDN settings.
- Whether the failure affects all visitors, one network, one browser, one format, or one image size.
Ask the host to check web-server, PHP, WAF, and CDN logs for the request. Those logs can distinguish a missing file from a permissions denial, rate limit, upstream timeout, or policy block that WordPress cannot see.
Quick Recap
Use this final verification checklist
- The direct URL returns the intended image with a successful response.
- The page and every selected
srcsetcandidate use the correct HTTPS hostname. - Both WordPress URL fields match the production address.
- The uploads directory is writable by the WordPress process and publicly readable by the web server.
- The image format, dimensions, memory use, and browser support are appropriate.
- No theme, plugin, cache, CDN, WAF, hotlink, rewrite, CORS, or CSP rule blocks the request.
- An external image has been replaced with a permitted local copy when long-term availability matters.
- Lazy-loading has been tested only where relevant and has not been mistaken for a server-delivery failure.
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.
