What Does a Screenshot Actually Prove?

Hashing a screenshot at capture and timestamping the hash independently establishes one thing well: that the file has not changed since the timestamp was issued. It does not establish where the content came from, how the capture was made, or whether the image fairly represents anything. A hashed and timestamped screenshot of a locally fabricated page satisfies every integrity check and proves nothing about the service it appears to show.

A screenshot arrives in a bundle. It shows a post, a listing, a message, a price, a term of business. Someone will now ask whether it is genuine, and the argument that follows will usually be the wrong argument.

It will be about whether the image has been edited. That question has a technical answer, and the technology to answer it has been available for years. Hash the file at the moment of capture, timestamp the hash with an independent authority, and any subsequent change to that file becomes detectable by anyone who cares to check. Within its own terms this works, and it is genuinely useful.

It is also now available free. Tools offer capture with hashing and independent timestamping at no cost, marketing themselves explicitly against services charging a few hundred dollars per capture. Whatever that means commercially, it tells you something technically: detecting change to a file is not where the difficulty lies.

Which leaves the other half.

What the seal does not reach

Integrity controls attached to a captured image all operate at the same moment, after the browser has produced the pixels. They establish that the file you are holding matches the file that was hashed, and they say very little about what put the content on the screen in the first place.

Consider four situations. In each one, the capture is genuine, the hash is correct, the timestamp is independent, and the signature validates.

The interface was never real. A convincing message thread can be produced in a design tool, in a browser's developer console, or by one of the many services that exist to generate exactly this. The screenshot is a genuine screenshot of a genuine screen. The conversation never happened.

The page was edited in place. Developer tools allow extensive modification of a live page's content and appearance. The address bar is correct, the certificate is valid, the domain is real, and two lines of the text have been changed by the person who captured it.

The response never came from the internet. A hosts file entry redirects a domain to the local machine. Doing that over HTTPS then requires a certificate the browser will accept, which can mean a trust store the collector controls, a browser launched with validation disabled, or simply serving the page over plain HTTP where the site is not preloaded for strict transport security. None of these is difficult, and the result displays the expected address while serving content from a folder.

The content was real, and only ever sent to that one session. Pages vary by account, location, device, language and experiment allocation. A service can accurately deny that content was generally available while a capture accurately shows it was transmitted to one session.

In all four, the integrity controls did exactly what they were designed to do. They were answering a different question from the one being asked of them.

The question that replaces it

The old question was whether a file had changed since it was hashed. That one is close to settled and it is commoditising to zero. The question that replaces it is what produced the file.

Answering that needs something the pixels cannot supply: evidence about the exchange itself. What connection was made, what the remote party proved about itself, and what came back over it.

How much that actually buys is worth being careful about, because the field overclaims in one direction and undersells in the other. The short version is that a handshake can be tied to whoever controlled the certified key, and a third party can check that for themselves rather than taking the collector's word for it. The content that followed cannot be tied to them the same way, because it is protected with keys the collecting client also holds. So the handshake is established, and the content is corroborated by that rather than proved by it.

The detail matters, and the summary above does not survive contact with an expert.

Three things, not one

None of this makes screenshots or recordings worthless, and the claim that it does is both popular and wrong.

A screen recording is the artefact that most directly preserves the displayed sequence: what appeared, in what order, and what was done. Other sources can evidence some of the same ground, including input logs, browser history and application audit trails. But the recording preserves the visual sequence in a way a network capture does not, and if an investigator is accused of fabricating a search, both artefacts contribute and neither is complete on its own.

Rather than ranking them, it is more useful to stop treating them as interchangeable and be precise about which of three questions each one speaks to.

What was observed. The visual record. What appeared on the display, in what order, and what actions were visible.

What was transmitted. The application and network record. What the remote service sent, including material that reached the client without ever appearing on screen.

What can be independently verified. The material a third party can check for themselves, and the assumptions that check rests on.

These overlap. A recording can be integrity protected, and a signed message is both transmitted and verifiable. But most disputes about online evidence turn out to be a disagreement about which of the three is actually in issue, and naming it early tends to shorten the argument considerably.

Where this stops

Setting out the limits is part of the argument rather than a caveat attached to the end of it.

Proving what a server transmitted does not prove the statement was true. A server can be compromised, can host false user content, or can be operated by someone with an interest in the outcome. It does not identify who was operating either end. It does not establish that the right material was collected, which is a failure mode no acquisition technology addresses. And it rests on assumptions about the collecting machine, its software, its clock and its trust store, all of which should be named rather than waved at.

The practical answer is not a better single artefact. It is collecting more than one layer, and reporting which layer each fact came from, so that a reader can see what is established, what is corroborated, and what is neither.

---

Shorenet builds evidence acquisition technology. We publish what our approach cannot establish alongside what it can.