Screenshots as evidence in UK courts: What they prove, and what they don’t.

This page covers civil and family proceedings in England and Wales. Criminal proceedings have their own procedure rules, and Scotland and Northern Ireland have their own rules of evidence; neither is covered here. It is general information and not legal advice, and every legal point links to the rule it rests on so you can read the rule rather than take our word for it.

Can screenshots be used as evidence in court?

Yes. A screenshot is ordinary documentary evidence, and courts receive them constantly: in contract and debt claims, in employment disputes, in family proceedings, in insurance and fraud work. Investigators take them, solicitors bundle them, claims handlers attach them.

Being usable is not the same as being persuasive. Whether a screenshot is admitted and what weight it carries are different questions, and the second is for the court to decide on the whole of the evidence. Most screenshots are never tested, which is why the practice works. The trouble starts with the one that is.

Are screenshots admissible in UK courts?

Usually, yes. We are not aware of any rule that excludes a document merely for being a screenshot. But admissibility is the start of the argument rather than the end of it, and it is not entirely in the parties’ hands.

There is a positive rule about copies, which is what a screenshot is. Under section 8 of the Civil Evidence Act 1995, where a statement in a document is admissible in civil proceedings it may be proved by producing the document or, “whether or not that document is still in existence”, a copy of it, “authenticated in such manner as the court may approve”. It does not matter how many removes there are between the copy and the original, and the Act defines a document as “anything in which information of any description is recorded”. So a screenshot can in principle be put forward as a copy. How it has to be authenticated is for the court, which is the whole of this page in one sentence.

In civil proceedings, CPR 32.1 lets the court control the evidence by directing “the issues on which it requires evidence”, “the nature of the evidence which it requires to decide those issues” and “the way in which the evidence is to be placed before the court”, and provides that the court “may use its power under this rule to exclude evidence that would otherwise be admissible”. The family court has the same power in FPR 22.1, which adds that the court “may permit a party to adduce evidence, or to seek to rely on a document, in respect of which that party has failed to comply with the requirements of this Part”.

So the practical question is not “is this admissible” in the abstract. It is what issue the screenshot goes to, whether the court wants evidence on that issue in that form, and what happens if somebody disputes it.

Family proceedings differ in two ways worth knowing: the family court has an express power to permit reliance on a document despite non-compliance, and the test for permitting expert evidence is that it is “necessary”, rather than the civil test of “reasonably required”. Outside children proceedings that test is in FPR 25.4; in children proceedings it is in section 13 of the Children and Families Act 2014. We set that out in social media evidence in the family court.

How can the other side challenge a screenshot?

By serving a notice to prove. In most civil claims and in family proceedings, the authenticity of a disclosed document is admitted by default, and a party who wants it proved has to say so, in time.

CPR 32.19 provides that a party “shall be deemed to admit the authenticity of a document disclosed to him under Part 31 ... unless he serves notice that he wishes the document to be proved at trial”. That notice must be served by the latest date for serving witness statements, or within 7 days of disclosure, whichever is later.

Two limits on that rule. It bites only on documents disclosed under Part 31, and it does not apply to claims on the small claims track: CPR 27.2(1) disapplies Part 31 and Part 32 other than rule 32.1 for small claims.

It is not hypothetical. In Peters v Joseph [2026] EWHC 775 (Ch), screenshots of emails were admitted as fresh evidence on appeal. The judge said that on their face they appeared to be genuine screenshots of genuine emails, but the person shown as sending them said she had never sent them, so their authenticity could only be decided at a trial where she could be cross-examined. He sent the question of whether a disputed declaration of trust was forged back for a re-trial, at which the emails can be relied on.

FPR 22.16 does the same in family proceedings: a party to whom a document is disclosed “is deemed to admit the authenticity of that document unless notice is served by that party that the party wishes the document to be proved at the final hearing”.

There is a separate notice requirement worth checking for evidence such as plans and photographs that is not contained in a witness statement, affidavit or expert report, is not to be given orally at trial, and is not evidence of which prior notice must be given under CPR 33.2. CPR 33.6 provides that “[u]nless the court orders otherwise the evidence shall not be receivable at a trial unless the party intending to put it in evidence has given notice to the other parties in accordance with this rule”, with the timing depending on what it is being put in for. Whether a particular screenshot falls inside that rule is a question for the case and for advice on it. The point is that it is worth checking rather than assuming. Part 33 does not apply on the small claims track either (CPR 27.2(1)(d)).

And a challenge does not have to prove that your screenshot was faked. There is an easier argument to make: that faking it was available, trivial and undetectable. How much weight a court gives that is for the court, but it is a much lower bar to clear, and it has just been cleared for everybody.

Can screenshots be faked?

In under a minute, with no specialist software and no skill worth mentioning. Rather than tell you, we will show you: below are three screenshots of one conversation. One is an authentic capture. The other two were fabricated. Have a look, then pick one.

The bar is not proof, it is doubt

This is the part that tends to get missed.

A screenshot can lose much of its value well before anyone proves it was faked. Once its authenticity is put in issue, the party relying on it has to be able to prove it, and pointing out how easily it could have been altered may be enough to put them to that proof. How much weight the image then carries is for the court, on all the evidence.

So the question is not whether you were fooled today. It is what you would say in a witness box to someone who asked how you know.

Screenshots are still the default

This matters because the screenshot remains the standard way evidence from the web reaches a case file. Investigators take them. Solicitors bundle them. Claims handlers attach them. HR teams paste them into reports. They are accepted, filed, disclosed and relied on routinely.

The assumption underneath that practice is that faking one convincingly is hard. It was never especially hard. It is now trivial, and the tools ship with every browser and sit behind every chat interface.

The practice has not caught up. It will, and when it does, a great deal of otherwise sound evidence is going to become arguable.

You cannot detect your way out of this

The instinct is to look for a detector. Something that examines the image and tells you whether to trust it.

That works, sometimes, for wholly generated images. It cannot work here.

Panel B has no generation artefacts because nothing was generated. No unusual compression, no telltale noise, no model fingerprint. It is a real capture of a real render. Every forensic property you might test is authentic, because it is authentic. It is simply authentic to a page that was altered before the shutter went.

Detection is also a race against whoever is generating, and anything you build gets beaten by the next model. But the deeper problem is not that fakes are improving. It is that the screenshot was never carrying the information you needed in the first place.

The courts have noticed. Guidance for judges in England and Wales published on 31 October 2025 says that AI tools are now being used to produce fake material, including text, images and video. It notes that courts and tribunals have always had to deal with forgeries and allegations of forgery, and says judges should be aware of this new possibility and of the potential challenges posed by deepfake technology. It is written for judicial office holders: it is guidance, not a rule of evidence.

One of them did declare itself

Panel C arrived carrying a content credential: a signed manifest, conforming to the C2PA standard, stating that the image came from a generative model. Read with the right tool, it names itself.

That is worth having, and it is worth being exact about what it did.

It identified the fabrication and said nothing whatever about the authentic capture. Panel A carries no credential, so the manifest cannot tell you panel A is real. It can only tell you panel C is not. An absent credential means nothing at all, which is the situation almost every image is in.

It could not see panel B. Panel B is a real screenshot of a real render, so no participating tool ever touched it and there was nothing for a manifest to attach to. That is not a gap in the standard. A credential describes what a cooperating tool did to a file. It has no way to mark a file that no cooperating tool ever handled, which is exactly the route available to anyone with a browser.

And it did not survive being handled at all. Opening the file and saving it again removed it, in the ordinary tools we reached for. No crop, no format change, no compression involved. It does not take a hostile act to lose a content credential, or even a lossy pipeline. It takes a routine one. A screenshot of the screenshot loses it, as does a paste into a document, a messaging app, or a print to PDF. None of the surfaces these images actually travel through preserves it or shows it to anyone. By the time a screenshot reaches a case file it has usually been through several of them, and nobody along the way was looking.

None of that is an argument against content credentials. It is an argument about where the proof sits. A credential travels with the file, which means whoever holds the file can remove it. What you want is something the holder could not have produced and cannot take away.

Does hashing or timestamping a screenshot make it reliable?

It makes it unchanged, which is a different thing. Hashing a screenshot at capture and timestamping the hash proves the file has not been altered since that moment, and proves nothing at all about where the content came from. Panel B above would hash and timestamp perfectly: it is a genuine, unedited capture of a page that was altered before the shutter went.

That is the whole of the argument in a paragraph. At length, with the distinction between integrity and authenticity set out properly, it is in unchanged is not the same as accurate and what does a screenshot actually prove?

How do you capture web evidence properly?

Most of the answer has nothing to do with us, so take this part first. Whatever tool you use:

• Capture immediately. Nothing can witness a page after it has changed. Every other step is downstream of this one.
• Capture the context, not the fragment. The full page or thread, the account, the URL as text rather than as pixels, and the visible timestamps.
• Keep the original untouched. Do not crop, annotate, resize, convert or re-save it. Work on copies. Annotating the original is one of the most common ways a sound capture becomes arguable.
• Write a contemporaneous note. Who captured it, when, from what device and browser, whether logged in and as whom, and the steps taken in order. Written at the time, not reconstructed later. “Is this forged” is hard to prove either way; “tell me how you made this” is a question you can answer, if you wrote it down.
• Record the hash of each original, understanding what it does and does not establish (see the section above).
• Account for custody. Who has had access to the files, and when.

There is a step-by-step version of this for posts and profiles in how to preserve social media evidence before it is deleted.

Doing all of that well produces a careful record that still rests on your word. That is the gap the rest of this page is about.

The witness was there the whole time

When that page loaded, the server did something on your behalf that it cannot take back.

Modern web traffic is encrypted with authenticated encryption, which means every chunk of data the server sends carries a cryptographic tag computed over the exact bytes, with a key that exists only because of that specific connection with that specific server.

Change one byte and the tag no longer matches. The server produced that tag as a routine part of serving the page. It had no idea it was creating evidence. It could not have refused, and it cannot revoke it afterwards.

We call that the Unwitting Witness®. It is the difference between recording what a screen showed and holding the server’s own authentication of the session. There is more on the mechanism in how it works.

How do you prove a screenshot is real?

One witness is not enough

An honest objection: the party doing the capturing also holds the session keys. In principle they could generate matching tags themselves. A tag alone proves the bytes are internally consistent, not that they ever crossed a wire.

So we do not rely on one witness.

• The server produces the tags, involuntarily, as described above.
• Our relay, independent of whoever captures the evidence, sits in the network path and signs the encrypted traffic flowing from server to client as it passes. It never holds the session keys and never sees the content. It attests only that these exact encrypted bytes travelled this path; trusted time comes from a separate timestamp authority. We operate it. The capturing party does not operate it.
• A timestamping authority anchors the bundle to a trusted clock.

The keys alone are no longer enough: to fabricate what the relay witnessed, someone would also have to get forged traffic to it from outside the tunnel, which is far harder than editing a file. What remains is trust in the relay we operate, and connections resumed without a fresh handshake, which a capture reports separately. How it works sets out both. The same argument, at length, is in What does a screenshot actually prove?

What comes out

A capture produces a bundle: the encrypted traffic, the server’s tags, the relay’s signature, the timestamp, and everything needed to check them against published trust anchors.

The design point is that checking requires nothing from us at the time of checking. No live Shorenet service, no account, no permission, no cooperation.

That is only worth anything once the validator is public, and it is not yet. Shorenet is pre-deployment, and publishing it is part of deployment rather than an afterthought, because evidence that only the vendor can check is evidence that asks to be taken on trust.

What you can see today is narrower, and worth being exact about: a demonstration of the decryption step, run in your own browser on a sample baked into that page. It is not the validator and it does not accept a bundle of your own.

Why this is about more than one screenshot

The same gap runs through a much larger category of casework than most people expect, and the law has already moved in a direction that makes it worse. We set that out in The law doesn’t ask if it’s fake.

About this test

The three panels are screenshots of one conversation on a demonstration messaging site we run, carrying a wholly fictional thread. The site is live and readable, and is marked not to be indexed, because a fabricated conversation on the domain of a company selling evidential integrity is a bad search result to own.

Panel A is an unaltered capture. Panel B is the same page with one word edited in the browser before the screenshot was taken, so the file is an honest capture of a dishonest render. Panel C is panel A passed through a generative model with one sentence of instruction.

Which panel is which is not something you have to take on trust. The identification was derived from the message data the live site actually served, which sits outside all three image files, and everything needed to repeat that is published:

• the three lossless originals, at capture-1.png, capture-2.png and capture-3.png, under their collection names rather than their panel letters
• thread.fetched.json, the copy of the served message data retrieved when the panels were identified, kept so the check still works if the demo site is ever edited
• verify-panels.py, the script that does the comparison

We have deliberately not published how the altered panel was made, or the instruction given to the model. Neither is secret and neither is difficult, which is rather the point, but a page arguing for evidential integrity should not double as a tutorial.

Cite this

For a reference list or a footnote:

Shorenet, “Screenshots as evidence”, shorenet.co.uk, 2026. https://shorenet.co.uk/screenshot-evidence/

The page is a permanent URL and is revised in place, so cite the date you read it. /real is a short alias that redirects here and is safe to print, but the canonical address is the one above.

If you are quoting the figure above the fold, quote the sample size with it and describe it as what it is: a self-selected sample of people who chose to take an online test on this page. It is not a survey of investigators, lawyers or courts, it was not sampled or weighted, and it should not be reported as a measure of how often screenshots are faked or detected in real casework. Press enquiries: contact us.

About Shorenet

Shorenet builds evidence technology for the web. Trawler captures browser traffic as a desktop application. Keel does the protocol work underneath. Pilot, our relay, is the witness in the path: independent of whoever captured the evidence, though not of us.

What it does not do, stated plainly on a page that has spent this long on fakery: Shorenet does not detect deepfakes or synthetic media, and we do not claim to. It proves what a website sent, never that what it shows is true. Often what matters is that something was published, and that is the part it proves. It also captures only what you open in a capture browser, not native mobile apps, and it cannot reach anything deleted before the capture was made.

If your work depends on web content being believed later, we should talk.

Talk to us