Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

If an image is missing, start with the browser’s evidence rather than changing CSS at random: open Developer Tools, reload the page, and inspect the image request in the Network panel. The request’s URL, HTTP status, response type, Console messages, and computed styles usually identify whether the file is missing, blocked, deferred, or delivered but hidden.

A 404 points to a wrong or undeployed path; a 403 to access or hosting rules; a 5xx to a server problem. A 200 or 304 means the browser received something, so investigate decoding, responsive source selection, lazy loading, or layout. The sections below turn that evidence into a repeatable fix.

1. Check whether the browser requested an image

  1. Open Developer Tools (right-click the page and choose Inspect, or use your browser’s developer-tools shortcut).
  2. Open the Network panel, enable the Img filter if available, and reload the page.
  3. Open the affected request. Record the final URL, status, response headers, and whether the response is actually an image.

MDN explains that the Network panel shows requested assets and timing: How do you make sure your website works properly?. If no image request appears, inspect the rendered markup first; the browser may have no usable source, may be waiting for a responsive or lazy candidate, or may have rejected the element before requesting it.

What you see Likely direction What to do next
200 The server delivered a response Check that it is valid image data, then inspect responsive selection, decoding, and CSS.
304 Not modified; a cached representation is being used Check whether a stale cached file explains a recent replacement; try a cache-busting reload.
403 Forbidden Review file permissions, directory rules, hotlink protection, authentication, and host configuration.
404 Resource not found Correct the URL, filename, case, upload, or deployment location.
500 or 503 Server-side failure or temporary unavailability Check application and host logs, then contact the hosting administrator if needed.

These statuses are diagnostic signals, not guarantees: a framework or proxy can customize responses.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

2. Verify the rendered source and deployed file

In the Elements or Inspector panel, find the actual <img> element. MDN’s reference states, “The src attribute holds the path to the image you want to embed” (MDN <img> reference).

  • Confirm that src is present and not empty, null, or accidentally set to the current page URL.
  • If srcset is present, identify which candidate the browser selected in the Network panel; do not assume the fallback src was used.
  • Compare the requested path with the deployed directory and filename. Fix spelling errors and upload files omitted from the deployment.
  • On case-sensitive deployments, match filename and directory capitalization exactly. Treat this as a deployment check rather than a universal browser rule.
  • Check URL encoding for spaces, non-ASCII characters, and characters such as # that can change the requested URL.

Open the image URL directly in a new tab. A direct 404 confirms a path or deployment issue; a login page, HTML error document, or other non-image response indicates routing or access configuration rather than a valid image.

Use a minimal known-good element

Temporarily replace the failing markup with a simple test using a confirmed file:

<img src="/images/test.jpg" alt="Test image">

If this works, compare the original element’s URL, attributes, and surrounding code. Keep useful alt text: it is the textual replacement when an image cannot be displayed and improves accessibility.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

3. Confirm that the response is valid and supported

A successful HTTP status does not guarantee display. MDN lists corrupted image data and unsupported image formats among image-loading errors (image element reference).

  • Inspect the response’s Content-Type and file bytes. A URL ending in .jpg that returns HTML is not a usable JPEG.
  • Open the file in an image editor or validate it with a known-good decoder. Re-export or replace a damaged file.
  • Test a format supported by the affected browser when compatibility is uncertain.
  • Check whether an image-processing or CDN transformation is returning a truncated or zero-byte result.

Do not “fix” a corrupt response with CSS; replace or repair the asset or the transformation that produced it.

4. Look for HTTPS, Content Security Policy, and cross-origin blocks

Mixed content

An HTTPS page that requests an HTTP image can trigger mixed-content handling. Browsers upgrade some insecure image requests and block others; behavior is not identical for every URL or browser. Serve images over HTTPS and read the Console warning. MDN’s guidance is documented in Mixed content.

Content Security Policy

A Content Security Policy can reject an otherwise reachable image host. The img-src directive lists permitted image sources; if it is absent, default-src can govern images (MDN img-src and CSP header).

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #3
The New Real Book
  • Used Book in Good Condition
  1. Read the exact CSP error in the Console.
  2. Identify the host in the rejected URL.
  3. Add only the intended trusted origin to the applicable img-src policy (or adjust default-src deliberately).
  4. Reload and confirm that the Console no longer reports the violation.

Do not broaden a policy to * merely to hide an error; that removes useful protection.

Cross-origin nuance

An ordinary <img> can generally display a cross-origin image while restricting script access to its pixels through a canvas. Adding crossorigin changes the request to a CORS request and requires the remote server to opt in for your origin. Investigate CORS when the Console reports it or when canvas pixel access is the actual requirement; do not add CORS headers reflexively to every broken image.

5. Check responsive images and lazy loading

srcset, sizes, and picture

Responsive markup can request a different file than the one you inspected. For <picture>, the browser evaluates each <source> element’s srcset, media, and type, then uses the nested <img> as fallback (MDN picture). With srcset, width or density descriptors and sizes influence candidate selection (Using responsive images).

  • Resize the viewport to reproduce the failure.
  • In Network, identify the selected candidate and open that URL directly.
  • Check every srcset URL for spelling, deployment, format, and permissions.
  • Ensure the type condition for formats such as WebP or AVIF matches files your target browsers support.

Lazy loading

loading="lazy" intentionally defers offscreen requests. Scroll the image near the viewport before deciding it failed. A lazy image may not have loaded when the page’s load event fires (MDN image reference). For testing, temporarily remove the attribute or move the element into view, then restore the intended behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

6. When the request succeeds but nothing is visible

If the correct image returns 200 or 304 and decodes, inspect the element and computed styles in Developer Tools (What are browser developer tools?).

  • Check computed display, visibility, opacity, width, height, and clipping.
  • Inspect parent containers for zero dimensions, overflow clipping, collapsed flex or grid tracks, or an unexpected stacking context.
  • Look for overlays covering the image, including consent dialogs, menus, and pseudo-elements.
  • Disable suspicious rules one at a time in the Styles pane, then make the smallest permanent CSS change.

This branch is a presentation diagnosis: changing the URL or server headers will not fix an element that is successfully delivered but hidden by layout.

7. A repeatable fix workflow

  1. Reproduce: note browser, viewport, URL, account state, and whether the issue affects one image or many.
  2. Capture evidence: Network URL/status/response, Console messages, and the rendered markup.
  3. Classify: no request, 403/404/5xx, successful-but-invalid response, security block, deferred candidate, or rendering problem.
  4. Change one thing: correct the path, deploy the file, repair permissions, adjust HTTPS/CSP, fix responsive markup, or remove the hiding style.
  5. Verify variants: test a hard reload, a private window, representative viewport sizes, and an unauthenticated visitor path.
  6. Prevent recurrence: add deployment checks for referenced assets, monitor server errors, and keep CSP changes narrowly scoped.

8. Performance, caching, and reliability notes

  • Use appropriately sized responsive candidates; downloading a large desktop file for a phone can delay display without being a path error.
  • Keep cache behavior in mind after replacing an image. A 304 can legitimately serve an unchanged cached representation; invalidate or version the asset when the content changes.
  • Lazy loading reduces initial work but requires testing near-viewport behavior, not only the first screen.
  • When a CDN, optimizer, authentication layer, or proxy sits in front of storage, test both the public URL and the origin’s logs. The browser can only report the response it received.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Or skip the browser setup

For repeatable visual checks, ScreenshotNeo can request a page and return a PNG, JPEG, WebP, or PDF. Its clean-shot process accepts cookie or consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be disabled. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing result. It also provides an MCP server for Claude, Cursor, and other MCP clients, with take_screenshot, get_page_info, and capture_pdf tools.

Use the same URL you are diagnosing. Full API options and parameter details are in the ScreenshotNeo documentation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

cURL

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

Python

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)

Node.js

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

ScreenshotNeo supports full-page captures with lazy images loaded, CSS-selector element captures, custom CSS and JavaScript, waits for selectors, delays or network idle, request and resource blocking, custom headers/cookies/user agents, timezone and geolocation, dark mode, device presets, retina scale, transparent backgrounds, resizing, caching with a chosen TTL, signed links, asynchronous webhooks, bulk capture of up to 100 URLs per call, a usage API, and an OpenAPI specification. Its parameter names are compatible with those used by other screenshot APIs, which can simplify migration.

The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; yearly billing provides two months free, and every feature is included on every plan. Create a free ScreenshotNeo account and use the 1,000 monthly screenshots to verify your pages without adding a card.

9. Frequently overlooked checks

  • Authentication: a browser session may see an image that an anonymous visitor receives as 401 or 403. Test the real visitor state.
  • Service workers: an old cached response can survive a normal reload. Inspect Application/Storage tools and test without the worker when appropriate.
  • Redirects: follow the final URL in Network; a redirect to a login page or HTTP endpoint can explain both access and mixed-content errors.
  • Build output: verify that the production artifact contains assets referenced by generated HTML, not only files present in the source tree.

Frequently Asked Questions

Why does an image work locally but fail after deployment?

The deployed path, filename capitalization, upload, permissions, redirect, or host policy can differ from local development. Inspect the production request and compare its final URL and status with the local one.

Can an image return 200 and still be broken?

Yes. The response may be HTML, corrupted data, or an unsupported format, or CSS may hide a valid decoded image. Inspect the response type and computed styles.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Should I add CORS headers to fix every remote image?

No. A normal img can display cross-origin content without exposing pixels to canvas. CORS matters when the Console reports a CORS failure or your code must read the image through canvas.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.