How to Diagnose Image Delivery Issues on a Website

To diagnose an image delivery issue, reproduce it on the published page, inspect the image request in your browser’s Network panel, and use the request URL, status, response, timing, and selected image dimensions to identify the cause. A missing image is usually a path or response problem; a slow image needs timing analysis; an image that looks wrong or is too large may use the wrong responsive candidate. Change one thing at a time, then retest the same page and viewport.

Start with the live URL: hosting, paths, redirects, and caching can differ from a local environment. The browser’s Network panel shows what was actually requested and returned. A performance trace adds sequence and timing context. See MDN’s [guide to checking that a site works](https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Tools_and_setup/Checking_that_your_web_site_is_working_properly) and Chrome’s [Network panel documentation](https://developer.chrome.com/docs/devtools/network/).

1. Reproduce the image problem

Open the published page where the problem occurs. Record the page URL, approximate time, browser, viewport size, and device pixel ratio if relevant.
Describe the symptom precisely: absent, broken icon, wrong image, blurry, pixelated, unexpectedly cropped, oversized, or late to appear.
Try the same page at the affected viewport and, if possible, in a fresh session. Note whether the issue changes after reload or when the browser cache is disabled.
Open DevTools, select Network, enable Preserve log if navigation is involved, and reload. Filter by Img or search for part of the image filename.

Do not begin by recompressing the asset or rewriting markup. First establish whether the browser requested the expected image and what the server returned.

2. Diagnose a missing or incorrect image

Select the image request in Network and inspect the request URL, status, redirect chain, response headers, and Preview or Response tab. Compare the requested URL with the intended file path and filename, including capitalization and extension. A path that works on a case-insensitive development machine can fail on a case-sensitive host.

Evidence	Likely explanation	Next check
No image request appears	The element may not have loaded yet, may be lazy-loaded, or the markup or script may not have selected a source.	Scroll the image into view, inspect the element’s `src`, `srcset`, and `currentSrc`, and check the Console for script errors.
`404`	The requested path or filename is not present at that location.	Compare the exact request URL with the deployed asset path. Check base paths, filename case, build output, and routing rules.
`403` or another authorization error	The host, CDN, or origin denied access.	Check access rules, signed URL expiry, hotlink protection, and whether the browser request carries required credentials.
`5xx`	The origin or an intermediary failed to serve the image.	Check server/CDN logs and retry the exact URL. Determine whether the failure is intermittent or limited to a particular path or region.
`200` but wrong image	The URL may resolve to a different asset, a stale cached response, or an unexpected redirect target.	Inspect Preview, final URL, cache headers, and the deployed file. Compare a cache-busted request only as a diagnostic.
Request is blocked or marked failed	A browser policy, extension, mixed content, or network failure may prevent delivery.	Read the Console message and request details. Check HTTPS, content security policy, extensions, and proxy/network behavior.

A successful HTTP status alone does not prove the correct image was delivered. Inspect the response preview and final URL. The MDN troubleshooting guide covers missing images and HTTP status investigation.

3. Diagnose an image that loads slowly

In Network, inspect the image’s start time, waiting time, download duration, transferred size, and relationship to other requests. The waterfall helps distinguish a request that starts late from one that starts promptly but takes a long time to transfer.

Late request start: determine whether the image is lazy-loaded, discovered late by script or CSS, or held behind other work. For an above-the-fold image, verify that lazy loading is appropriate.
Long wait before bytes arrive: investigate server or CDN response time and the request’s dependency chain.
Long transfer: inspect transferred bytes, image format, dimensions, and connection conditions. Reduce unnecessary payload or serve a better-sized variant where appropriate.
Image request finishes early but display is late: inspect rendering work and the performance trace for main-thread activity, layout, or style work delaying presentation.

Use a browser performance recording or Lighthouse when the symptom concerns page load behavior or total page weight. Retest under comparable cache and network conditions; a warm cache can hide a delivery problem. MDN’s [performance fundamentals](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Fundamentals) explain the value of browser performance tools and reduced test cases when the cause remains unclear.

4. Check responsive source selection and image dimensions

An image can load successfully and still look blurry, cropped, or needlessly heavy because the browser selected an unsuitable source. Compare the rendered slot dimensions with the asset’s natural dimensions and the device pixel ratio. In the Console, inspect an image element’s currentSrc, naturalWidth, naturalHeight, and rendered size.

const img = document.querySelector("img");
({
  src: img?.src,
  currentSrc: img?.currentSrc,
  rendered: img && { width: img.clientWidth, height: img.clientHeight },
  natural: img && { width: img.naturalWidth, height: img.naturalHeight },
  devicePixelRatio: window.devicePixelRatio
});

Review the markup that controls selection:

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Product shown from the front">

For art direction or different crops, inspect each source in <picture>, its media condition, and the fallback <img>. Confirm that declared candidate widths match the actual files and that sizes describes the rendered slot. If a source is too small for the displayed size and pixel density, it can appear soft; if it is far larger than needed, it wastes transfer. Chrome recommends [properly sizing images](https://developer.chrome.com/docs/lighthouse/performance/uses-responsive-images?hl=en) and describes responsive candidates and image CDNs as ways to serve suitable assets.

5. Fix and verify the cause

Write down the evidence: request URL, response status and final URL, selected source, dimensions, and timing that match the symptom.
Choose the smallest relevant correction: fix a path or deployment rule, resolve an access/server failure, update responsive candidates or sizing, or adjust delivery behavior.
Change one variable so the result is attributable to that correction.
Reload the same published page at the affected viewport. Recheck the request and confirm the expected response, source, dimensions, and timing.
Repeat with a cold cache if the original issue involved stale content, and with a warm cache if repeat-view behavior matters.

For a repeatable investigation, save the page URL, viewport, approximate network conditions, request URL, response status, and a screenshot or trace. This makes it easier to distinguish a real fix from a transient success.

6. Choose a lasting image delivery approach

If evidence points to image selection or payload, two common approaches are responsive image markup and an image CDN. Responsive markup gives the site control over generated variants and browser source selection. An image CDN can transform or resize at request time and may suit pipelines that need dynamic variants or distributed delivery. Decide based on control of the asset pipeline, required variants, delivery geography, implementation complexity, and operating cost. Chrome’s documentation describes image CDNs as APIs for transforming images; verify any provider’s current terms and capabilities before choosing one.

Media is a substantial part of web transfer: MDN reports that media accounts for over 70% of bytes downloaded for the average website, covering images and video rather than images alone ([MDN multimedia guidance](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/Multimedia)). That broad statistic is context, not a diagnosis of any individual page.

Or skip the browser setup

For a quick visual check of the published page, [ScreenshotNeo](https://screenshotneo.com) is a website screenshot API and MCP server. A single request captures a URL as an image or PDF. See the [ScreenshotNeo API docs](https://screenshotneo.com/docs/) for parameters and response details.

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

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Replace the example URL with the page you are investigating. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. [Sign up for free](https://screenshotneo.com/account/sign-up/).

Troubleshooting checklist

Problem	Cause to investigate	Practical fix
Works locally, fails after deployment	Incorrect base path, filename case mismatch, missing build artifact, or host routing difference.	Inspect the live request URL and deployment output; correct the path or publish the asset.
Broken only on some pages	Relative URL resolves against a different page path, or a page-specific rule changes the source.	Inspect the resolved request URL on both working and failing pages; use an appropriate root-relative or generated URL.
Looks blurry only on high-density screens	Selected candidate has insufficient pixel dimensions.	Provide a higher-resolution candidate and verify `srcset` and `sizes`.
Downloads a large file in a small slot	Oversized candidate or inaccurate `sizes` declaration.	Generate appropriately sized variants and align `sizes` to actual layout.
Only fails intermittently	Transient origin/CDN failure, cache variation, or network condition.	Record timestamps and response headers, compare repeated requests, and inspect server/CDN logs.
URL opens directly but not on the page	Page security policy, mixed content, credentials, or cross-origin configuration may differ.	Inspect the Console and request headers; fix the specific policy or access requirement shown there.

Performance, reliability, and cost considerations

Performance: right-size the delivered image for its display slot and device density. Responsive variants can avoid transferring unnecessarily large assets. Use a trace to distinguish transfer time from delayed discovery or rendering.
Reliability: verify both cold and warm cache behavior when cache state could affect the symptom. For intermittent errors, preserve request timestamps and response details so logs can be correlated.
Operational cost: compare the cost of generating and maintaining variants with any image transformation or delivery service fees. Account for the number of variants, request volume, and required delivery geography; provider pricing and terms need current verification.
Page weight context: MDN’s media statistic includes video, so use measurements from the page under investigation to prioritize image work.

FAQ

Should I test the image URL directly?

Yes, as a follow-up check. The page’s Network request remains the primary evidence because it reveals the URL, headers, policies, and selected source used in the actual page context.

Does a 200 response mean the image is fixed?

No. Confirm that the response is the intended image and that it displays at the needed size. A successful response can still contain the wrong or stale asset.

When should I use an image CDN?

Consider one when dynamic transformations or distributed delivery fit the asset pipeline. Compare its current capabilities and operating cost with generating responsive variants in your own build.