Screenshot, HAR, WARC or PCAP: What Does Each Actually Prove?

There is a ladder of ways to preserve something seen online. Each rung answers a different question. A screenshot shows what a screen displayed. A hash shows a file has not changed. An archive shows what the collector wrote down. A network capture shows what arrived at the collector’s machine. Only a witness the collector does not control can show what the server actually sent, and even that has limits worth stating before anyone else does.

When online material matters, the first question is usually “is this genuine?” That question is too broad to answer. It hides at least four narrower ones, and each method of preservation answers a different set:

• What did the screen show?
• Has the file changed since it was captured?
• Did the capture really reach the website it claims to be from?
• What did the website actually send?

And a fifth that decides whether any of the others survive a challenge:

• Can the other side check it, without trusting whoever captured it?

The ladder

Method	Screen	Unchanged since	Reached the real site	What the site sent	Checkable without trusting the collector
Screenshot or screen recording	Yes	No	No	No	No
Screenshot plus hash and timestamp	Yes	Yes	No	No	No
HAR file	Partly	No	No	No	No
Web archive (WARC)	Replayed	If sealed	No	No	No
Capture service run by a vendor	Yes	Yes	Vendor’s word	Vendor’s word	Trusts the vendor, who is also the collector
Network capture, no keys (PCAP)	No	If sealed	Partly	No	No
Network capture with session keys (PCAP plus keylog)	Rebuilt	If sealed	Full handshakes	No	No
Capture witnessed by a relay the collector does not control	Rebuilt	Yes	Full handshakes	Witnessed, full handshakes	Trusts the relay’s operator and keys, not the collector

The rest of this note explains each row, because a table is only as honest as the reasoning behind it.

Screenshots and screen recordings

A screenshot is a picture of pixels. Nothing in the file connects it to a website: the same image can come from a design tool, a browser’s developer tools, an app built to fake conversations, or AI. A screen recording shows more, including scrolling and navigation, but it has the same limit. It records what the screen displayed, and the person capturing controls the screen.

Hashing the file and having the hash timestamped by an independent authority is genuinely useful: any later change to the file becomes detectable. But the hash is taken after the image exists. It proves the file has not changed, not where its content came from. A hashed, timestamped screenshot of a fabricated page passes every check. The longer argument is in What does a screenshot actually prove?

HAR files

A HAR (HTTP Archive) file is what a browser’s developer tools export: a JSON record of the requests and responses the browser handled, after the encryption was removed. It is often used as “technical” evidence because it contains headers and response bodies rather than pixels.

It is also plain, editable text. The standard has no certificate chain and no server signature. Some tools add summary fields, such as the TLS version, the server address or the certificate’s subject, but these are the browser’s own statements, not cryptographic material, and a browser may omit or truncate response bodies when it exports one. A HAR shows what the browser says it handled. Nothing inside it shows that a server sent any of it.

Web archives (WARC)

A WARC file is the standard format used by web archives. It records requests and responses as written by the capturing software, again after the encryption was removed. Some tools also record connection details, in metadata records or in fields proposed for the standard, and the standard records the server’s IP address. But even a WARC that stored the certificate and the handshake would still hold the decrypted exchange as the archiving software saw it, and, as the network capture section below explains, a record made on the collector’s side cannot show that the server sent the content.

WARC files carry content digests, but anyone who edits the file can simply recompute them. Archiving proxies write WARCs from whatever passes through them, so whoever controls the collector controls the record. Signed web archives (for example signed WACZ packages) add a genuine improvement: they show who made the archive and that it has not changed since. A well-run archive is trustworthy for many purposes, but that is trust in the archive. The same is true, to a different degree, of any witness, including ours: what differs is whether the witness could read or author the content, and whether it is separate from the collector.

Capture services run by a vendor

Some services load the page in the vendor’s own browser, on the vendor’s servers, and hand back a sealed capture with an affidavit. This is a real improvement on capturing something yourself, because the vendor is independent of you.

It moves the trust rather than removing it. The vendor’s browser sees the decrypted page and writes its own record, so the capture is only as good as the vendor’s honesty and security. The other side does not have to trust you, but it does have to trust the vendor not to alter the record, because the vendor is also the collector. (The vendor also sees the content, which matters for confidentiality rather than for integrity.)

Network captures (PCAP), with and without keys

A packet capture records the traffic that arrived at the collecting machine’s network interface. For a modern website that traffic is encrypted, so without the session keys a capture shows which address was contacted (often a shared content-delivery network) and, unless Encrypted Client Hello was used, which site name was requested, but not what was said.

With the session keys, which a browser can be told to write to a file, the traffic can be decrypted, and the capture gains something real. When a connection starts with a full handshake, the holder of the certificate’s private key signs it. That proves the certificate holder signed that handshake at some point, though not when, and the holder may be the site’s content-delivery network rather than the site itself. It also assumes the certificate was validly issued, which is checked against public roots. Resumed connections, which browsers use routinely, and older RSA key exchange carry no such signature, and in TLS 1.2 the signature covers only the key exchange rather than the whole handshake.

What a capture with keys cannot prove is the content. After the handshake, the traffic is protected with keys that both ends hold. The collecting machine holds them too, so it can create traffic the website never sent, with valid cryptographic tags, or inject it into the capture. Nothing in the file tells the two apart. The detail is set out in How it works.

A witness the collector does not control

The gap in every method above is the same: the only party that saw the traffic is the party making the case. Closing it takes a witness outside the collector’s control.

A relay in the network path can sign the encrypted traffic as it passes, from the network side. It never holds the keys, so it cannot read the content and does not hold what it would need to forge it. The collector holds the keys but not the relay, so faking what the relay witnessed would take far more than editing a file, though it is not impossible. That is the rung Shorenet is built on. You could call this network-attested evidence; we call it witnessed.

What “witnessed” does not mean

Stating the limits is part of the method:

• The relay is independent of the collector, not of whoever operates it. In Shorenet’s case, that is us, and we say so.
• Resumed connections carry no server signature. On a resumed connection the relay witnessed what came back, but the collector could have been the party answering. That content is not treated as coming from the named website; those connections are reported separately and never rounded up.
• Witnessing proves transmission, not truth. If a website served a fake image, a witnessed capture proves the website served it, not that the scene is real.
• Nothing can be witnessed after it has changed. A capture made after a post is deleted proves nothing about what was there before.
• Turning bytes into a readable page is interpretation. The cryptography proves the bytes; the rebuilt page is a rendering of them, and uncertain reconstructions are quarantined rather than guessed.

For the practical question underneath this comparison, see screenshots as evidence.

Different evidence answers different questions. The only one worth building a new method for is the one the others cannot answer: what did the website actually send?