How to prove what a web page said

A page changes, or disappears, and now you need to show what it said. This comes up in disputes about prices and terms, in questions about what a model was told, in market settlements, and in every argument that begins “that is not what it said when I read it”.

Five methods are in common use. They are not interchangeable, and the expensive ones are not always better. I build one of them, so treat the recommendation with the suspicion it deserves and check the reasoning instead.

1. A screenshot

Free, instant, and worth very little on its own. Any image editor produces a convincing fake in under a minute, and the file's own metadata is equally editable. In a dispute the other side does not need to prove your screenshot was forged; they only need to observe that it could have been, and the burden lands back on you.

A screenshot is still worth taking. It is contemporaneous, it shows layout that a raw capture does not, and it costs nothing. Just do not expect it to settle anything by itself.

2. A public web archive

The Internet Archive's Wayback Machine, archive.today and similar services keep dated snapshots that a third party controls, which is a real improvement over your own screenshot. They are free, widely recognised, and often already hold the page you need.

Two limits matter. Snapshots are mutable: a later robots.txt rule or a takedown request can withdraw one, and evidence that can vanish is a poor foundation for anything that has to hold for years. And they give you a link rather than an artifact — nothing you can hand to a counterparty that verifies on its own machine.

3. Forensic capture with an affidavit

Page Vault, PageFreezer, Hunchly and similar tools render the page in a real browser, record a chain of custody, and — importantly — a person will sign a declaration about how the capture was made. Prices run from roughly $149 a capture, or around $99 a month upward for the subscription products, sometimes with an implementation fee.

If your destination is litigation, this is the right category and the others are not. A court cares about the human declaration and the chain of custody at least as much as the hashes. It is also the only method here that reliably handles JavaScript-rendered pages and social media.

4. A timestamp on a hash you made yourself

Hash the bytes you saved and submit the digest to a free OpenTimestamps calendar, or to an RFC 3161 timestamp authority. You get proof that that exact content existed by that time, anchored in a Bitcoin block or signed by an authority, for nothing.

This is genuinely useful and under-used. Its limit is what it cannot say: nothing about where the bytes came from. You are proving that you had this content on that date, which settles arguments about later alteration and settles nothing about origin. If the dispute is with the person you would be showing it to, your own record is the one thing that cannot resolve it.

5. A third-party signed receipt

A service fetches the source itself, hashes what it received, signs a record of what was served and when, and appends that record to a log it cannot quietly rewrite. This is what Elucora does, and what the rest of this page is about.

The difference from method 4 is who observed the fetch. The difference from method 2 is that you hold a signed file rather than a link. The difference from method 3 is that nobody signs a declaration about it — which is exactly why it is cheaper, and exactly why it is not a litigation exhibit.

How to choose in one paragraph

Going to court, or capturing a social post or an app-like page? Use a forensic capture service with an affidavit. Need evidence for your own records, and control the content already? Hash it and timestamp it — free, and enough. Need someone who distrusts you to accept what an external source served, at scale, inside a pipeline? That is the case a signed third-party receipt exists for.

What a receipt establishes, precisely

Being exact here is more useful than being enthusiastic. A valid Elucora receipt establishes:

• These exact bytes were served at this URL at this time — as observed by Elucora, not by you.
• The quoted passage or JSON field is the one that was pinned, and matches its own hash.
• The record has not been altered since: ES256 over RFC 8785 canonical JSON, checkable against published keys.
• The entry sits in a public append-only log. An RFC 6962 inclusion proof shows membership in about a dozen hashes; a consistency proof shows an older published root is a prefix of a newer one, so an entry edited or removed in between leaves no valid proof.
• The time did not come from Elucora alone: an RFC 3161 token from a timestamp authority, and a Bitcoin anchor that anyone with a copy of the chain can check.

It does not establish that the source was telling the truth. Nothing in this list does. If a page said the rate was 4.2% and the rate was not 4.2%, you now have proof of what was published — which is frequently the more useful fact.

The limits, before you find them yourself

• Captures are HTTP, not a browser. A page that builds its content with JavaScript is captured as the shell the server sent. Filings, feeds, APIs and article pages work well; single-page apps and social posts do not.
• There is no affidavit. Nothing here is offered as court-admissible; that is a matter for a court and its rules.
• Elucora is trusted at the moment of capture. The receipt proves what Elucora was served. Everything after that instant is verifiable without trusting Elucora at all, but that instant is a real assumption.
• The service is young, run by one person, and the log is publicly countable. You can count it yourself.

Trying it without an account

Verifying and reading receipts need no credentials at all — a receipt anyone hands you can be checked immediately, and the API documentation shows how to do it offline against published keys. Capturing needs a free key: 500 receipts a month, no card.