The Complete Digital Evidence Checklist for 2026

1. Visual Evidence - Full-Page Screenshot with URL and Timestamp

Why it matters: A screenshot is the most intuitive form of evidence. It shows exactly what a visitor would see on the page. But a bare screenshot - without a visible URL or timestamp - proves nothing. Anyone can open developer tools, change the text, and take a screenshot. The URL and capture time must be embedded directly in the image, not added after the fact.

Without it: Opposing counsel argues the screenshot is fabricated. There is no way to connect the image to a specific website or a specific date.

How to get it: Use a server-side capture tool that renders the page on its own infrastructure and overlays the URL, UTC timestamp, and file hash directly onto the image. Avoid browser screenshots - they are trivially editable and carry no metadata proving origin.

2. Source Code - HTML/DOM Preservation

Why it matters: A screenshot shows the surface. The source code shows the structure. Hidden elements, meta tags, embedded links, tracking scripts, code comments, and CSS class names all live in the HTML. If someone copied your code, stole your metadata, or hid deceptive content behind a visual facade, the source code is where you prove it.

Without it: You can only prove what the page looked like - not what it actually contained. Courts increasingly expect source-level evidence for web disputes, especially in copyright and trademark cases involving code-level copying.

How to get it: Save the complete HTML DOM at the moment of capture - not just the initial server response, but the fully rendered DOM including JavaScript-generated content. Store it as a standalone .html file alongside your screenshot.

3. Cryptographic Hash - SHA-256 Fingerprint

Why it matters: A SHA-256 hash is a unique digital fingerprint of a file. Change a single pixel in a screenshot or a single character in an HTML file, and the hash changes completely. By recording the hash at the time of capture, you create an unforgeable proof that the file has not been altered since it was created.

Without it: There is no mathematical proof that the file you present today is the same file that was captured months ago. The opposing side can claim you edited it.

How to get it: Generate the SHA-256 hash immediately after capture and store it in the evidence record. Anyone can later verify the hash by running shasum -a 256 filename in any terminal.

4. Trusted Timestamp - RFC 3161 from a Recognized Authority

Why it matters: A hash proves a file has not changed, but it does not prove when the file was created. Your system clock is trivial to manipulate. An RFC 3161 trusted timestamp is issued by an independent Time Stamp Authority whose clock and signing key you cannot control. It is a cryptographic receipt proving your evidence existed at a specific moment in time.

Without it: You cannot prove when the capture happened. Opposing counsel argues you fabricated the evidence after the fact - after the page changed, after the dispute arose, or after a deadline passed.

How to get it:Submit the SHA-256 hash to a recognized TSA (Time Stamp Authority) that follows the RFC 3161 protocol. The response is a signed .tsr file that any third party can verify independently using the TSA's public certificate.

5. Network Evidence - HAR Archive of HTTP Requests

Why it matters: A HAR (HTTP Archive) file records every HTTP request and response that occurred during the page capture. It shows which servers were contacted, what resources were loaded, the response headers, status codes, and timing. This is the network-level proof of what actually happened during the capture - not just what appeared on screen.

Without it: There is no proof of how the page was loaded or what servers responded. In cases involving redirect chains, injected content, or third-party scripts, the HAR file is often the most important piece of evidence.

How to get it: Capture the full network traffic during page rendering. The HAR format is an open standard supported by all major browsers and capture tools. Store it alongside your screenshot and source code.

6. Domain Evidence - WHOIS Records

Why it matters: WHOIS records show who registered the domain, when it was registered, when it expires, and which registrar manages it. In domain disputes, trademark cases, and fraud investigations, knowing who controls the domain is as important as knowing what it displays.

Without it: You can prove what the page showed but not who was responsible for it. Domain ownership changes hands, and WHOIS records can be updated at any time. If you do not capture them at the same time as the page content, the ownership record may look different later.

How to get it: Query the WHOIS database for the domain at the time of capture and store the full response. This should happen automatically alongside the page capture so everything is timestamped together.

7. DNS Evidence - Where the Domain Pointed

Why it matters: DNS records show which IP address a domain resolved to at the time of capture. This proves which server actually served the content. In cases involving hacked websites, DNS hijacking, or CDN configurations, DNS evidence establishes the connection between the domain name and the server that delivered the page.

Without it: The domain could have been pointing to a different server at the time you captured the evidence. Without DNS records, there is no proof that the content you captured actually came from the server the domain owner controlled.

How to get it:Resolve the domain's A, AAAA, CNAME, MX, and NS records at capture time and store the results. DNS changes propagate quickly, so these records must be captured simultaneously with the page content.

8. TLS Certificate - SSL Certificate Proving Server Identity

Why it matters: The TLS (SSL) certificate proves the identity of the server that served the page. It shows which Certificate Authority issued the certificate, which domain it covers, its validity period, and the encryption details. A valid TLS certificate confirms that the captured page was served by an authenticated server - not an impersonator or a man-in-the-middle attacker.

Without it: There is no proof that the page was served by the legitimate domain owner. In phishing cases, impersonation disputes, or any situation where server authenticity matters, the absence of certificate evidence weakens your case significantly.

How to get it: Extract the full certificate chain during the TLS handshake at capture time. Store the certificate details - issuer, subject, validity dates, serial number, and fingerprint - as part of the evidence package.

9. Server-Side Capture - Third-Party Rendering

Why it matters: If you take a screenshot in your own browser, you had the opportunity to modify the page before capturing it. Developer tools make this trivial - anyone can change text, hide elements, or inject content with a few clicks. A server-side capture eliminates this objection entirely. The page is rendered on an independent server that you do not control, producing evidence that is inherently more credible than anything captured on your own machine.

Without it: The opposing side argues that you manipulated the page before capturing it. This is the single most common objection to web evidence, and without server-side capture you have no strong rebuttal.

How to get it: Use a capture service that renders pages on its own servers using a headless browser. The capture should happen in a clean environment with no extensions, no cached data, and no user modifications - producing a neutral, independent record of what the page displayed.

10. Evidence Bundle - Everything in One Verifiable Package

Why it matters: Individual evidence files are useful, but they are strongest when packaged together in a single archive that cross-references everything. An evidence bundle ties the screenshot, source code, hashes, timestamps, network logs, domain records, DNS records, TLS certificate, and capture metadata into one ZIP file with a verification summary. The bundle is self-contained - anyone who receives it can verify every item without needing access to any external system.

Without it: You are assembling evidence from multiple tools, renaming files, zipping them manually, and hoping you did not miss anything. Files get separated, context gets lost, and the chain of custody becomes harder to establish.

How to get it: Use a tool that generates a complete evidence package automatically. The bundle should include a plain-text verification file listing the SHA-256 hash of every item, so any recipient can independently confirm that nothing has been tampered with since capture.

The Full Checklist at a Glance

Each item on this list addresses a specific objection that can be raised against digital evidence. Together, they form a package that is extremely difficult to challenge in court, in arbitration, or in any formal dispute process.