If the page renders and the images are broken, the HTML is fine and something about the image requests is not. Open the network panel, reload, and read the status column against the four causes below.

404 - the path is wrong

curl -sSI https://yourdomain.com/img/rack.webp | head -1\nls -la /var/www/site/public/img/rack.webp

On Linux the filename is case sensitive. Rack.webp and rack.webp are different files, which is why a site developed on Windows or macOS loses its images the moment it is deployed.

403 - it exists and cannot be read

sudo -u www-data test -r /var/www/site/public/img/rack.webp && echo readable || echo NOT readable\nnamei -l /var/www/site/public/img/rack.webp

namei walks every directory in the path. One parent directory without execute permission blocks everything below it while the file itself looks perfectly correct.

Blocked, or mixed content

An image requested over http on an https page is blocked by the browser and shown in the console as mixed content. See mixed content after switching to HTTPS. An ad blocker will also drop anything whose path contains words like ads or banner.

200 and still not shown

  • The file is not the format its name claims - an HTML error page saved as .jpg, for example.
  • A CDN returned a cached error. Purge that path and request it again.
  • The image is there and has zero height, which is CSS, not the file.
file /var/www/site/public/img/rack.webp\ncurl -sS https://yourdomain.com/img/rack.webp | head -c 20 | xxd | head -2
If everything above is fine locally but broken through a proxy, request the origin directly with --resolve and compare. That splits the problem in half in one command.