Blog

What a website screenshot can and cannot prove

A still image is a record of one render. It is not the HTML, the headers, or proof of what a signed-in user saw.

Teams attach screenshots to incident reports because a picture is fast to read. That is a good reason to take one. It is a bad reason to treat the file as a complete record of the site.

What you actually have

You have pixels from one Chromium render of a public URL, at a stated size, after a bounded wait. If the site returned HTTP 404, the picture is of that response. If a cookie banner covered the hero, the picture includes the banner. If a font was still loading when the timer ran out, the picture may use a fallback font.

The file does not include the HTML, the response headers, the certificate, or the list of requests the page made. It does not show content that appears only after a login, a click, or a long scroll past the height cap.

What it is fine for

Design QA, a visual note in a ticket, a preview in a report, and a check that a public page is up and roughly intact. Taken on a schedule you control, a series of shots can show that a hero, a price, or a headline changed. One shot cannot show how long the page was like that, or that every visitor saw the same thing.

What to collect instead when it matters

If you need to defend a claim about uptime or content, keep the image together with the URL, the time, the viewport, and a note of the HTTP status SnapSite showed. For anything behind an account, or for a legal archive, use a process that is allowed to authenticate and to store the response itself. SnapSite is deliberately not that process.