Building useful websites
Website images not loading? Trace the URL, response and layout
Inspect one missing picture from requested URL to visible layout, then verify the repair on the public page.
1. Find the image request the browser actually made
Choose one missing picture on a published page and copy the page’s final URL. This guide covers HTML image elements, including responsive images. CSS backgrounds need their own inspection.
In desktop Chrome, open DevTools → Network, reload, and find the image request. Scroll to the picture if it is lazy-loaded. Select the row and record Request URL, status and Content-Type in Headers. Check Preview or Response to see what arrived. Chrome’s Network reference explains these controls.
If there is no matching request, inspect the image element in Elements. Check its src, srcset and any surrounding picture/source elements. An absent or empty source, lazy loading or script that has not populated the element needs a different repair from a server error. Keep any browser blocking message as evidence.
2. A 200 response can still contain the wrong thing
An image URL ending in .svg or .jpg is only an address. Inspect the response: a login page, missing-page template or application shell is HTML, even if the status is 200. Compare Content-Type with the body and preview; the header alone cannot prove that the bytes form a usable image.
Coru’s local test on 21 October 2026 served HTML with status 200 at /fallback/card.svg. Chromium 155.0.8059.12 could not display it as an image: naturalWidth was 0, while complete was true. Changing the filename or reading only the status would miss the routing error.
- 404: check the exact resolved address and whether the file was deployed there.
- 403 or a login redirect: inspect the access rule and final response for that request.
- 200 with HTML: repair the fallback or image route so the intended image bytes arrive.
- An image response that still fails: check whether the file is damaged or its format is supported by the target browser.
3. Resolve the path from the published page
MDN documents how relative URLs use a base URL. Our fixture reproduced this with src="images/card.svg": from /notes/page/ it requested /notes/page/images/card.svg; from /notes/page it requested /notes/images/card.svg. The trailing slash changed the destination. Neither was the fixture’s working /images/card.svg.
A leading slash starts at the base URL’s origin root. Usually this is your page’s origin; a base element pointing to another origin changes it. If your site is published under /project/, /images/card.svg does not include that prefix: the intended URL might be /project/images/card.svg. Choose the path that matches the actual deployment.
A base element can change relative URL resolution across the document. In our second fixture, base href="/assets/" made src="card.svg" request /assets/card.svg. In Console, document.baseURI shows the base being used. Check it before changing every image path. MDN’s base reference explains this document-wide effect.
4. Match the deployed filename exactly
Compare the requested path with the deployed file, including uppercase letters, extension and folder name. MDN notes that many servers distinguish letter case. A file that works locally can therefore fail after deployment; the outcome depends on the server’s routing and storage.
Our deliberately case-sensitive test route returned 200 for /images/card.svg and 404 for /images/Card.svg. This demonstrates that configuration, not a rule that every server behaves identically. Repair the reference or deployed filename, then verify the public URL. Confirm that the file entered the release at all before changing image compression.
5. If only one device fails, inspect currentSrc
Select the actual img element in Chrome Elements, then type $0.currentSrc in Console. It reports the selected image URL; $0.src shows the resolved src value. MDN explains that currentSrc can differ when srcset is present and does not establish successful loading.
Our fixture had a working src="/images/card.svg" and srcset="/missing-large.svg 2x". At device pixel ratio 2, Chromium selected the missing large candidate and the image failed. Opening only the working src would have tested the wrong resource.
Check the selected candidate and its Network response at the failing viewport and device pixel ratio. Then repeat at another relevant size. Repair missing srcset or picture candidates and verify their deployed URLs. This step diagnoses missing resources; use the related sizing guide for sharpness and download-size decisions.
6. Separate missing image data from hidden layout
With the img element selected, inspect $0.complete and $0.naturalWidth. MDN documents that complete can be true for a broken image. naturalWidth describes intrinsic, density-corrected width; zero can mean unavailable image data or an image without intrinsic width. Read these clues alongside the request and rendering, not as a universal success test.
Our original 120 × 80 SVG loaded successfully while display:none gave it a zero-width visible box. Its naturalWidth remained 120. The resource existed; CSS hid it. In Elements → Computed, inspect the image and its ancestors for display, visibility, opacity, zero dimensions or clipping. Temporarily toggle the responsible rule to test the explanation, then fix the stylesheet.
The local experiment used one Chromium build and explicit routes. It did not test your CDN, permissions or browser security policy. A browser error naming a blocked resource needs that specific policy checked.
7. Retest one repair through the public page
Keep this short record: page URL → selected image URL → status and returned content → intrinsic dimensions and visible box → cause → repair → result after an ordinary reload. Record viewport and device pixel ratio for responsive failures.
Success means the intended picture appears in context at the tested sizes, with its useful detail and alternative text intact. Reopen the public page after deployment and check another page that shares the asset. If you still receive an old image or old HTML, continue with the related stale-page guide. A successful upload message alone does not verify delivery.