The client means well. They have spent months capturing everything, and now your inbox holds a shared-drive link to thousands of screenshots: HEIC files and PNGs named IMG_4471, crops of crops, the same conversation captured three times, and a few photos of a laptop screen. When a client sends screenshots as evidence at this volume, reading them in file order is the slowest and least reliable way to find what matters.
What works is triage. Preserve the set exactly as received, impose structure, code against the issues, and identify which conversations need a proper export instead of screenshots. The workflow below is written for paralegals and legal assistants doing that first pass under attorney supervision. It ends with a short, prioritized working set and a memo the attorney can act on, and it keeps the original files clean in case authenticity is ever challenged.
What should you do first when a client sends a pile of screenshots?
Freeze the set before anyone works on it. Preserve the files exactly as delivered, fingerprint them, log how they arrived, and ask the client to pause further uploads until you send instructions. Everything downstream depends on being able to show that the files you reviewed are the files the client gave you.
- Download the complete set as delivered. Avoid previews or sync tools that silently convert HEIC to JPEG or strip metadata.
- Store one read-only “as received” copy and do all review on working copies.
- Generate a SHA-256 hash for every file and record it with the file name, size and format.
- Log the delivery: date received, channel, sender, file count, and any note the client included.
- Confirm the client still has the phone or account the screenshots came from, and that nothing has been deleted.
The phone matters more than the screenshots. In federal court, Rule 37(e) of the Federal Rules of Civil Procedure addresses electronically stored information that should have been preserved and was lost, and state courts have their own preservation rules. The client’s device or account is usually the most complete record, so the first message back to the client should protect it.
Sample wording
Thank you for sending these. Please pause on sending more for now so we can organize what we have. In the meantime, please do not delete any messages, conversations, photos or apps from your phone or accounts, do not crop or mark up any more screenshots, and keep the phone itself. We will send specific instructions for exporting the conversations that matter most.
How do you remove duplicates without losing anything?
Separate exact duplicates from near-duplicates and treat them differently. Exact duplicates can be suppressed from review; near-duplicates are grouped, never deleted.
Exact duplicates
Files with identical hashes are the same file, byte for byte. Suppress all but one from the review queue and keep a record of which files were suppressed and which copy stands in for them. Nothing is removed from the as-received set.
Overlapping scroll captures
Clients often capture a long conversation one screen at a time, so consecutive images overlap by a few messages. These are different files with different hashes, but they belong together. Group them into a run, give the run an ID, and review it as one unit in order. Check the last image of each run carefully: a near-duplicate that adds a single new message is not a duplicate.
Cropped, highlighted and annotated copies
When the client has circled, highlighted or typed notes onto an image, look for the clean version and flag the annotated one. Annotated images rarely make good exhibits, and the attorney will want to know they exist.
How should screenshots be sorted before anyone reads for substance?
Sort by source, then conversation, then date. Relevance review goes much faster once the pile has structure, and structure exposes gaps you would otherwise miss.
- Bucket by source. Text messages, WhatsApp, Facebook or Instagram messages, email, social media posts, photos of paper documents, and everything else.
- Group by conversation. Within each source, group by counterpart or group chat. One conversation can span hundreds of images.
- Date each item from what is visible. Record the message date shown on screen, not the file’s creation date, which reflects when the screenshot was taken. Many screenshots show only a time or a relative label such as “Yesterday”; record what is visible and mark the date as inferred if you work it out from context.
- Flag what cannot be dated or attributed. Undated fragments and images where the contact name is unclear go on a question list for the client.
- Index it. One row per file or run, using the fields below.
| Index field | Why it matters |
|---|---|
| Source and conversation | Drives grouping and shows which threads need a full export |
| Message date (as shown) | Places the item in the chronology |
| Capture date (file) | Shows when the client took the screenshot, which can matter on its own |
| Hash and run ID | Ties every reference back to an untouched original |
| Tier and issue tags | Filled in during coding |
How do you code screenshots for relevance without reading every word?
Code against the attorney’s issue list, in a time-boxed first pass, using a small number of tiers. Before coding starts, get the issues in writing: the elements of the claims and defenses, or the factors the court weighs in this type of matter. Coding without that list turns into a subjective read that no one else can check.
| Tier | Meaning | Next step |
|---|---|---|
| Key | Bears directly on a listed issue | Attorney review; candidate for full export |
| Context | Background or sequence | Feeds the chronology |
| Low | No apparent bearing | Retained; no further work |
| Sensitive (flag) | Possibly privileged, minors, third-party private data, intimate images | Segregate; attorney decides |
Watch for screenshots of the client’s own messages with your firm or a prior lawyer. Those belong in the possibly-privileged bucket, not the evidence set, and they should not travel with anything that might be produced.
Text extraction makes the set searchable, which is often the fastest way to find every mention of a date, place or name. AI-assisted extraction helps here, but its output is a search aid until a person checks it against the image. ABA Formal Opinion 512 makes the same general point about generative AI tools: the lawyer remains responsible for verifying what the tool produces. Never quote extracted text in a memo or filing without comparing it to the source image.
When should a screenshot be replaced with a full export?
Whenever the conversation is likely to matter. Screenshots are selective by design, and a selective record invites problems a complete export avoids.
- Completeness. Federal Rule of Evidence 106, the rule of completeness, lets the opposing party require that related portions be considered alongside the part offered. Three cropped messages invite that request; a complete thread answers it in advance.
- Authentication. Rule 901 permits authentication through a witness with knowledge or through distinctive characteristics. A full export with a recorded hash, plus the client’s testimony, is usually a sturdier foundation than a cropped image.
- Originals. Under Rule 1001(d), an accurate printout or other output of electronically stored information can count as an original, but disputes about accuracy are far easier to resolve when the source export exists.
- Symmetry. If the other side produces the full thread, your screenshots will be measured against it.
State evidence codes often track the federal rules but differ in places, so the attorney decides what is needed in your forum. For the export itself, compare the options in exporting iMessages for litigation and WhatsApp evidence in litigation. On the intake side, a tool like Evidence Helper can bulk-ingest screenshots and photos, normalize HEIC files, preserve and hash the originals on arrival, and make the set full-text searchable while you code.
What should the attorney receive at the end of triage?
A short working set and a one-page triage memo, not the pile. The goal is to let the attorney make decisions in one sitting.
- Triage memo: what arrived, when and how, total files, exact duplicates suppressed, runs grouped, date range covered.
- Key-tier items in chronological order, each tied to an index row and hash.
- Conversations recommended for full export, with the reason for each.
- Sensitive and possibly privileged items, segregated and listed.
- Items with authenticity questions: annotations, missing contact names, inconsistent timestamps.
- Gaps: periods with no material, plus the open questions for the client.
From here, Key and Context items feed the case chronology, and later collection rounds go through a structured request rather than another dump.
What goes wrong in screenshot triage?
Most problems come from skipping structure or touching originals.
- Reading in file-name order, which scrambles conversations and hides gaps.
- Treating file dates as message dates.
- Deleting “duplicates” that are actually different crops, or near-duplicates with one new message.
- Quoting extracted text that no one checked against the image.
- Letting the client keep sending small batches with no index, so every batch restarts the work.
- Mixing privileged screenshots into the evidence set.
Rules on preservation, authentication and privilege vary by jurisdiction. Decisions about what is relevant, privileged or admissible belong to the supervising attorney licensed where the matter is pending; triage makes sure those decisions are made on an organized, verifiable record.
