Website images not showing: the causes

If an image is broken for every visitor, the problem is on your website: the server answers with an error instead of the file, because the file was deleted, moved, or is linked at the wrong address. If it only fails for you or for one visitor, the cause is more often on that device: an extension, a connection, a setting.

Images are not the only files that go missing. Stylesheets, scripts and fonts fail the same way, often with nothing to show for it. These missing files are part of what the website bugs audit checks.

Visitor-side or site-side: two different problems

Most advice online is aimed at the visitor: clear the cache, try another browser. That fixes a local problem. When the fault is on the website, every visitor gets the same error, and nothing they do will fix it.

Every file a page requests gets a response code. HTTP status codes in the 400 range mean the server cannot fulfill the request, the best known being 404, "not found". Codes in the 500 range mean the server itself failed. Either way, the file never arrives.

A missing image shows, a missing script or font does not

The browser does not warn the visitor. It displays the page with whatever it received, and the result depends on which file is missing.

An image: an empty frame or a broken-image icon in its place, often on a product page or an about page.
A stylesheet: the layout partly falls apart, or completely if it was the main stylesheet.
A script: the feature it ran stops responding, much like a JavaScript error, except that no script failed. The file simply never arrived.
A font: the text shows in a fallback font. The content stays readable, but the page no longer matches your brand.

Where missing files come from

A missing file almost always has a cause you can date: a change on your site, or at a service your site depends on.

A migration or redesign: files move to new folders, but pages and posts written earlier still point to the old addresses.
A file deleted from the media library while a page still uses it. Nothing warns you when you delete it.
A file served by another company that has shut down or changed its address: an embedded widget, a library hosted elsewhere, a discontinued service.
An image resizing service that rejects a malformed request: it answers with a 400 error instead of a 404, and the image is just as missing.

Why you don't see it on your own site

Your browser keeps a copy of files it has already received and reuses it as long as it counts as fresh, without asking the server again. MDN's guide to HTTP caching describes how this works. A file deleted from the server can keep showing on your screen while every new visitor gets an error.

Other reasons add up: you browse the site logged in, on the pages you know, and images further down only load as you scroll. The broken file sits on a page you never open, or below the point where you stop scrolling.

What the audit records, and what it leaves out

The audit loads each sample page in a browser, as a first-time visitor would. It scrolls the page to trigger images that load on demand, then records every file the page actually requested and the code it received. The report gives the file address, the exact code and the pages affected.

A resource counts as broken when it receives a code in the 400 or 500 range. Three cases are left out, because they do not point to a missing file:

A protected resource (codes 401 and 403): it requires a login or a permission. It is noted as an observation, not as a defect.
A temporary refusal from the server (codes 429 and 503). During an audit, it is most often triggered by the pace of our own visits, and the same file often loads normally when requested again.
An address in the code that the page never requests, such as a fallback image the browser did not need. Only what a visitor actually receives counts.

The browser also writes a console message when a file fails to load. That message is the same defect seen twice: the audit counts it here, once, and not as a JavaScript error. A single missing file requested by the shared page template can appear on every page of the site: the warning then counts only once, and the report lists the pages affected.

What is quick to fix, and what takes a project

A file requested by the site's shared template, such as a logo, an icon or a configuration file, is fixed once for every page: put the file back, or remove the reference. A third-party service that has disappeared can be replaced or removed.

After a migration, hundreds of pages can still point to old addresses. Rewriting them, or redirecting the old addresses to the new ones, is work to plan, and it has to be checked page by page afterwards.

What this check doesn't tell you

We see the files requested by the sample pages, on load and while scrolling. Files that only load after a click, in a gallery, a tab or a logged-in page, are out of reach.

A file that fails intermittently can respond normally at the moment of our visit. We record the code received, not the reason the file disappeared.

By Quentin Mathis, Z29K · updated September 28, 2026