SHORENET
← Shorenet Guides Social media

How to Preserve Social Media Evidence Before It Is Deleted

Capture it now, record how you did it, and expect to be asked to prove it later

By Dr Anthony Rose-Edwards

Published , last reviewed

Preserve it now, and preserve more than a picture of it. Capture the post before it is edited or deleted, record who captured it and when, keep the original file untouched, and keep whatever lets somebody else confirm the capture is genuine. Nobody can preserve a post after it has gone, and the step that most often fails later is not the capture itself but the account of how it was made.

This guide 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. For the wider picture, see social media evidence in UK courts.

What does “preserving” a post actually mean?

It means creating something that still shows what was published after the original has changed, and that can be shown to be a faithful record.

Those are two different jobs, and most practice only does the first. A screenshot captures what the screen showed. It does not carry anything that lets a third party confirm the content came from the account and the platform it appears to come from, which is the question that gets asked when somebody disputes it. We set that argument out in full in what does a screenshot actually prove?.

So think of preservation as three questions a reader of your evidence will ask:

  1. What was published? The content itself.
  2. When, and by which account? The context around it: handle, display name, timestamps, reply chain, follower counts, whether it was public.
  3. How do I know this record is faithful? The part that fails.

How do you preserve social media evidence?

Good practice first, independently of any product.

  • Act immediately. Deletion and editing are the normal case, not the exception. Everything below is worthless if you do it next week.
  • Capture the whole context, not the fragment. The post, the account page, the thread above and below it, the URL, and the visible timestamps. A quoted sentence with no surrounding thread invites the argument that it was taken out of context, and that argument is usually available.
  • Capture the URL as text, not just as pixels. A screenshot of a browser window may not show the full address.
  • Record the time of capture, and the time source. Your own device clock is a claim, not a fact.
  • Record who did it and what with. Name, role, device, browser, and the steps taken, written at the time rather than reconstructed later.
  • Do not crop, annotate, resize, convert or re-save the original. Keep the original file exactly as it came off the capture, and work on copies. Annotating the original is one of the most common ways a sound capture becomes arguable.
  • Record the hash of each original file. A hash shows the file has not changed since you recorded it. Be clear with yourself about what that does and does not establish: it proves the file is unchanged since the hash was taken, not that the file shows what the platform served. That distinction is the subject of unchanged is not the same as accurate.
  • Keep it somewhere you can account for. Who has had access, and when.
  • Consider asking the platform, and do not rely on it. Platform records can carry attribution a capture cannot, but they take time, they usually require legal process, and the post may be gone before anything arrives.

Does a screenshot count?

Yes, in the sense that a screenshot can be put in evidence and routinely is. That is a different question from whether it will survive a challenge.

The route by which you get asked to prove it is worth knowing in advance. In civil proceedings, 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”. So authenticity is admitted by default, and a party who wants it proved has to say so, 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.

Family proceedings have the same mechanism in FPR 22.16: a party to whom a document is disclosed “is deemed to admit the authenticity of that document unless notice is served” that the party wishes it proved at the final hearing.

Two practical consequences. Unless a notice to prove is served in time, a disclosed screenshot’s authenticity is treated as admitted. And if yours is the one that is, the work of being able to prove it had to be done at capture time, because by then the post may not exist.

There is also a notice requirement to be aware of 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 given screenshot falls inside that rule is a question for the case and for advice on it; the point here is simply that it is a rule worth checking rather than assuming. Part 33 does not apply on the small claims track either (CPR 27.2(1)(d)).

What if the post has already been deleted?

Then your options narrow sharply, and honesty about that is more useful than hope.

Nothing can witness a page after it has changed. What may still exist is a copy somebody else made: a public web archive, a platform record obtainable through legal process, a copy held by another party, or a device belonging to a participant in the conversation. Each of those brings its own questions about provenance, and none of them is as good as a capture made while the post was live.

The longer treatment, including what still works and what generally does not, is in how to prove an online post existed, and when you can’t.

What should you write down at the time?

A short contemporaneous note, made while you are doing it rather than afterwards, covering:

  • the exact URL, as text
  • the date and time of capture, and where that time came from
  • who captured it, and in what role
  • the device, operating system and browser
  • what you did, in order, including anything you clicked to expand or scroll
  • whether you were logged in, and if so as whom
  • the filenames and hashes of the originals
  • anything you noticed that might matter later: an edit marker, a “translated” label, a truncated thread, a view count

This is dull and it is the part that holds up. “Is this image forged” is hard to prove either way. “Tell me how you made this” is a question you can answer, and a note written at the time answers it in a way that recollection months later does not.

Where Shorenet fits

Shorenet exists for the third question above, the one a screenshot cannot answer: how does somebody else know this record is faithful?

A Shorenet capture’s evidence is the web traffic itself, not a picture of the screen (a screen recording can run alongside as a guide to what the user saw, but it is the traffic that is sealed and checkable), and the traffic crosses a relay we operate that is independent of whoever is doing the capturing. The relay never decrypts and we never see the content; it signs fingerprints of the encrypted traffic as it passes. The result is sealed, so any later change shows, and it is built to be checked by anyone holding it, including the other side’s expert, without any Shorenet server, account or cooperation.

Being exact about the tense, because it matters: that is the design, and the validator it depends on is not published yet. Shorenet is pre-deployment. What exists today is a demonstration of the decryption step that runs in your own browser on a sample baked into the page; it is not the validator and it does not accept a bundle of your own.

Being exact about the limits, because they matter more than the capability:

  • It shows what the website or platform sent. It does not show that the content is true, and it does not show who was at the keyboard. If a false claim was published, a capture goes to the platform having served it under that account.
  • It does not detect deepfakes or synthetic media, and we do not claim to.
  • It cannot capture anything that was already gone.
  • It records what you open in a capture browser, not native mobile apps. Telegram on the web works today; WhatsApp support is in development. The current position per platform is in the FAQ.

How it works sets out the mechanism and what you have to trust us for. The honest comparison against screenshots, HAR files and web archives is in screenshot vs WARC vs PCAP.

Sources

Primary sources, each fetched and checked on 12 October 2026, and checked against the Ministry of Justice consolidated rules on 12 October 2026. Every rule quoted above is quoted from these.