Guide Errors & Troubleshooting

How to fix images that will not load

A page full of broken image icons could be a wrong path, a permission, or a blocked request — here is how to tell them apart.

Updated 7 min read Beginner

Broken image icons in place of pictures mean the browser tried to load a specific file at a specific address and got nothing usable back — a missing file, a permission it wasn't allowed past, or a request blocked outright. Unlike a whole page failing, this is nearly always narrow and mechanical: the HTML asked for something at an exact path, and that exact path didn't deliver.

Start with what the browser actually requested

Right-click a broken image and open it in a new tab, or check the network tab in developer tools, to see the exact URL the browser tried and the HTTP status it got back. That single piece of information — a 404, a 403, or a blocked request — points straight at the relevant cause below rather than requiring you to guess.

The causes, in the order worth checking

1. The path is wrong, often only by capitalisation

If the status is a 404, the file genuinely isn't at that address. Confirm the exact path in your file manager, checking capitalisation character for character — Header-Logo.png and header-logo.png are different files on Linux hosting even though they look interchangeable on a Windows or Mac development machine. This is by a wide margin the most common cause after a site has been built locally and then uploaded or migrated.

2. The images were never uploaded, or were excluded from a migration

Some migration and backup tools skip files above a certain size, or exclude specific folders by default. If a meaningful number of images are missing rather than just one or two, check whether the uploads folder on the new location actually contains everything the old one did, comparing folder sizes as a quick first check before comparing file by file.

3. Mixed content is blocking images referenced over plain HTTP

If the site runs on HTTPS but individual images are referenced with a hardcoded http:// address, browsers may withhold the secure padlock and, in some configurations, decline to display the image at all. See fixing a mixed content console error for how to find every instance rather than just the obvious ones, and why a plain database find-and-replace can make WordPress content worse rather than better.

Hotlink protection is designed to stop other websites embedding your images without permission, and it works by checking where a request claims to have come from. Configured too strictly, it can end up blocking legitimate requests from your own pages — particularly when images are served from a different subdomain, a CDN, or over a different protocol than the rule was written to expect. If the status code for the broken images is a 403 rather than a 404, this is worth checking before anything else.

5. File or folder permissions are too restrictive

The uploads folder and the images inside it need to be readable by the web server process — folders at 755, files at 644. A restore or manual upload that didn't preserve permissions correctly can leave images technically present but unreadable, which also presents as a 403 rather than a 404.

6. A CDN or cache is serving a stale or broken reference

If images loaded correctly before a recent change and broke immediately afterwards with no obvious cause, a caching layer holding an outdated version of a page — one that still points at an image path that has since changed — is worth ruling out. Purging the cache for the affected pages is a quick way to test this before looking further.

Check one broken image thoroughly before assuming they all share a cause

Confirm the exact status code for a couple of different broken images on the same page. A mix of 404s and 403s across the page means you're looking at more than one problem at once, not one cause with several symptoms.

A quick way to test a single image directly

Copy the exact image URL from developer tools and load it directly in a browser tab, on its own, with no page around it. This isolates whether the problem is with the image itself and its path, or something about how the surrounding page references it — a relative path built incorrectly, for instance, will often work when the direct URL is corrected but fail when loaded exactly as the page constructs it.

If the cause still isn't clear

Send us the exact URL of one broken image, along with the status code shown in developer tools. That single data point is normally enough for support to tell you directly whether the file is missing, blocked, or unreadable on the server.

Frequently asked questions

Why did images stop loading right after I moved my site to new hosting?

This is one of the most common triggers for exactly this problem, and it is almost always a case-sensitivity issue. Development environments on Windows and macOS generally ignore capitalisation in file paths; Linux hosting, which is what nearly all web servers run, does not. A path that worked perfectly during development can fail the moment it is live if the capitalisation does not match exactly.

Some images load and others on the same page do not. What does that tell me?

It rules out a site-wide cause such as a permissions problem on the whole uploads folder, and points instead at something specific to the images that fail — a small number of files genuinely missing, a mixed-content issue affecting only images referenced with a full http:// address, or hotlink protection misconfigured for one specific source.

Related reading