Why one image fails while the rest of the page loads

The page loads, the text renders, and one picture is a broken icon. The reflex is to blame the tunnel, because the tunnel is the thing that changed. Before that, find out which URL the browser actually requested for that image, because the page URL and the image URL are two different pieces of evidence. Most missing-image reports resolve to a host that never got a working request, and that answer costs one look at the Network panel.

Three conditions decide where to look

The first condition is whether the image comes from the same host as the page. A separate image host needs its own name resolution, its own connection and its own TLS identity, so a page that loads says nothing about it.

The second is whether the browser blocked the request before sending it. Mixed content, content security policy and referrer rules can stop an image without producing an ordinary server response, which is why no failed request appears in the list.

The third is whether delivery succeeded and rendering failed, a case where the bytes arrive and the picture still does not appear. Those three conditions have three different owners, and only the first one is a network question.

Find the resource the browser actually selected

The URL you see in the page source is often not the URL that was requested. Source sets, picture elements and CSS backgrounds all let the browser choose a different resource based on viewport width, pixel density or format support. A lazy-loaded image may not be requested at all until the page reaches a particular state.

Inspect the element and the request together, and keep the initiator with the request when you report the problem. MDN's image-element reference covers source selection, loading behaviour and referrer controls in one place, which is enough to tell which attribute chose the failing URL.

Record the hostname, the status, any redirect chain and the response content type. A 200 that returns a sign-in page is not a usable image, and a redirect to an HTML error page looks identical to a broken file until you read the type.

Read the status before the network

A timeout, a denied request and a decoding error need different next steps, and the status code is what separates them. A timeout points at resolution, route or a host that is not answering. A denied request points at a policy or an authorization layer. A decode error points at the bytes or the format.

If the request never appears at all, stop looking at the network and look at the markup. The most common cause is a source set entry that the browser preferred and that no longer exists on the server, followed by an element that a script never made visible.

That distinction alone prevents most of the wasted effort in this class of report.

When the browser blocks it, there is no response to read

Mixed content is the classic case: an HTTPS page that requests an image over plain HTTP gets the request blocked rather than failed, and the console records the reason. Content security policy produces the same shape, with the blocked directive named in the message. A referrer policy that strips the header can also cause a hotlink-protected host to return a placeholder instead of the picture.

Read the recorded reason before touching the network path, because these blocks do not improve when the route changes. Adding cross-origin permissions is not the fix either: displaying an image from another host and reading its pixels in a canvas are different operations, and only the second one needs the headers people paste in.

For a site you administer, correct the resource URL, the response or the policy at its owner and keep the authorization and referrer requirements intact. For a site you do not control, send the page and request evidence to its support channel instead of republishing private or expiring resource links.

Compare paths without changing the evidence

If you do want to test the access path, hold everything else constant: same page, same account, same selected image, one permitted path changed. Compare the request entries side by side rather than the rendered result, because the rendered result tells you whether the image appeared, not why.

A picture that loads on a new route does not prove that route is authorized, and a picture that stays broken does not prove the tunnel is at fault. If the image was removed or access is intentionally restricted, use a supported alternative rather than disabling certificate checks or mirroring someone else's protected material.

Order of work: identify the selected URL, read its status and type, check for a recorded block reason, then compare one path change at a time.