How to Fix Images Not Showing on a WordPress Website

Start by opening the image URL directly. If the file does not load in a new browser tab, investigate the file, URL, Media Library, permissions, or server. If it loads directly but not on the page, test the page markup, plugins, theme, and caches. This sequence narrows the cause without assuming one universal failure.

1. Identify where the image fails

Check the same image in four places:

Public page: Is the image missing for visitors?
Editor: Is it missing while editing the post or page?
Media Library: Does the attachment preview load under Media → Library?
Direct URL: Does the file open when you paste its URL into a new tab?

Also record whether the problem affects one image, images from one folder or domain, or every image. Note any recent migration, HTTPS or domain change, plugin or theme change, or cache change. These observations determine which checks to run next.

2. Test the image URL and page source

Right-click the broken image and copy its address, or inspect the page source and copy the src value.
Open that URL directly in a new tab.
Compare it with the URL shown for the file in Media → Library.
Look for a wrong domain, old directory, HTTP URL on an HTTPS site, misspelled filename, or a file extension that does not match the actual upload.

WordPress image output is based on an image URL; the developer documentation notes that wp_get_attachment_image_src() returns the image source data or false when no image is available. See the image URL documentation.

If a direct request returns 404, the file is missing at that address, has moved, or rewrite/server configuration is preventing access. If it returns 403, access control, hotlink protection, or permissions may be blocking it. A browser error such as a certificate warning points to HTTPS configuration rather than WordPress content.

3. Check the Media Library and local storage

Find the attachment in Media → Library and open its file details. Confirm that the item exists, the preview works, and its URL matches the URL used by the post, widget, template, or custom field.

Images inserted by URL depend on the remote source. WordPress warns: “If you don’t upload the image to your Media Library, the image may stop displaying later if the original file is moved, deleted, or no longer shared.” The remote site may also block embedding. If you have permission to use the image and need it to remain available, download it and upload a copy to your own Media Library. Read the Image block guidance.

For local uploads, verify that the expected file exists under the uploads directory and that WordPress can access it. WordPress documentation explains that correct permissions for wp-content may be required for uploads. Review media attachments and permissions.

4. Use Site Health to gather server facts

Open Tools → Site Health → Info. Record the WordPress and site URLs, HTTPS status, media handling details, upload limits, server configuration, directory locations, and filesystem permissions. The Filesystem Permissions section indicates whether required directories, including uploads, are writable.

Site Health is an information screen; it does not repair permissions. If an uploads directory is not writable, or if the host controls PHP, filesystem, or web-server settings, give the host the Site Health details and the failing image URL. See the Site Health screen documentation.

5. Isolate plugin and theme conflicts

When the direct image URL works but the page does not display it, isolate one variable at a time:

Clear or bypass any optimization, lazy-loading, security, or image-replacement plugin.
Temporarily deactivate plugins, then reactivate them one by one until the problem returns.
Switch briefly to a current default WordPress theme. If images return, inspect the original theme’s image markup, CSS, JavaScript, or template logic.
If the dashboard is unavailable, an administrator familiar with file access can manually deactivate plugins as described in WordPress troubleshooting documentation.

Do not leave a security or caching plugin disabled longer than needed for diagnosis. Make one change, retest the direct URL and page, and record the result.

6. Clear stale browser, site, and CDN output

After correcting a URL or replacing a file, hard-refresh the page or open it in a private window. WordPress notes that a browser can continue serving cached content after a change. Your setup may also have page, object, image-optimization, reverse-proxy, or CDN caches; purge the relevant cache only after confirming the source file and page markup are correct.

Check the response after purging. A cache can preserve an old 404, old HTML, or an outdated image URL, while a browser can preserve a previous response locally.

7. Fix pretty-permalink and rewrite-rule failures

Use this path only when the symptoms indicate it: image requests return 404s, pretty permalinks also fail, or the problem started after a migration or server move.

Go to Settings → Permalinks and save the current structure once to refresh rewrite rules.
Retest a failing image URL and a normal pretty-permalink page.
If the issue remains on Apache, ask the host to verify that mod_rewrite is enabled and that the site’s rewrite configuration is being read.
Have the host inspect .htaccess or equivalent server rules before editing them.

WordPress identifies Apache mod_rewrite as a possible cause of 404 errors with pretty permalinks and images. Read the common-errors guidance. Back up before changing server configuration, and ask the host to handle settings you do not control.

8. Handle external images and editor imports

An external image can disappear when its source URL changes, the file is removed, or the source blocks hotlinking. Confirm the remote URL in a separate tab and check whether the source permits display from another website.

If the problem occurs while importing an external image into the Block Editor, WordPress documents server-side sideloading of the URL into the Media Library. The same handbook describes browser cross-origin failures in the editor’s credentialless isolation context. That editor-specific behavior should not be treated as a universal explanation for every front-end image failure. Read the client-side media documentation.

9. Common errors and fixes

Symptom	Likely area	Action
Direct URL returns 404	Wrong, moved, or deleted file; rewrite rules	Compare the URL with Media Library, re-upload if needed, refresh permalinks, then ask the host about rewrites.
Direct URL returns 403	Permissions, hotlink protection, or access rules	Check Site Health and host security rules; verify that the source allows embedding.
Media Library item is missing	Attachment was deleted or migration missed files	Restore or upload the image and update the post URL.
Works directly but not on the page	Plugin, theme, CSS, JavaScript, or stale HTML	Test plugins one at a time, switch to a default theme, inspect markup, and purge caches.
Only remote images fail	Source URL, hotlink policy, or remote outage	Test the source directly; import a permitted copy into Media Library.
Images broke after migration	Old domain/path, HTTPS mismatch, missing files, or rewrites	Compare site URLs and attachment URLs, verify files, refresh permalinks, and involve the host.
Change is not visible after repair	Browser or site cache	Hard-refresh, test privately, then purge configured caches.

10. Performance, reliability, and cost considerations

Performance: A local, correctly sized image avoids dependence on a remote host. Lazy-loading, optimization, and CDN plugins can improve delivery but can also alter markup; disable them briefly when isolating a conflict.
Reliability: Keep important images in your Media Library when licensing permits. External URLs add a dependency on another site’s availability and embedding policy.
Server changes: Permissions and rewrite changes affect the whole site. Back up first and involve the host when settings are managed outside WordPress.
Cost: The diagnostic checks above require no paid tool. Hosting support may be the appropriate escalation when Site Health reports unwritable directories or server configuration problems.

Or skip the browser setup

For repeatable checks of public pages, ScreenshotNeo can capture a URL through one request. Its cleaner capture removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. An MCP server lets Claude, Cursor, and other MCP clients take screenshots or inspect pages. See the API documentation.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
const buffer = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('shot.webp', buffer);

You get 1,000 screenshots each month free with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Why do images work in the editor but not for visitors?

The public page may output a different URL or markup, or a cache, plugin, theme, permission, or server rule may affect front-end requests. Test the public URL directly.

Should I change file permissions myself?

Only if you understand the host’s filesystem model and have a backup. Site Health can show the problem; host-managed permissions should be fixed by the provider.

Will resaving permalinks fix every broken image?

No. It is relevant when image 404s occur with pretty-permalink or rewrite failures. A missing file, wrong URL, remote block, or plugin conflict needs a different fix.

Is a remote image automatically unsafe?

No, but it depends on another host. It can stop working if the source moves, deletes the file, or blocks embedding. Store a permitted copy locally when the image is important.