Send a large file straight to someone else

How it works

What "peer-to-peer" actually means here

It means the bytes do not come to us. The browsers negotiate a WebRTC data channel and the file crosses it directly. What passes through DocButterfly is the introduction: the offer, the answer and the network candidates that let two machines find each other.

From the first live two-party run on 3 September 2026, a 556 MB video between two homes on ordinary connections:

How this is protected

The channel between the two browsers is encrypted, and there is no setting that turns that off — a WebRTC data channel is DTLS or it does not exist. The keys are negotiated by the two browsers directly. DocButterfly holds no key, which is a stronger statement than a promise not to look: there is nothing here to look with.

While a transfer is running, the page reads the live connection and shows what the browsers actually negotiated — the protocol version, the cipher suite, and whether the path is direct. Nothing on that badge is written into the page in advance. If the browsers negotiate something other than an encrypted direct path, the badge says so.

What that does not cover: we introduce the two browsers to each other, so somebody who compromised our signaling could in principle introduce you to the wrong browser. That is the same shape of trust every end-to-end system asks for, and the honest answer is that a safety code you and the other person compare out loud is what closes it. That is not built yet.

The receipt

When a transfer finishes, each browser computes the SHA-256 of what it handled and sends only that digest back. Both halves are joined on the session code, and both parties are emailed a receipt saying the two digests matched.

Read the wording on it carefully, because it is deliberate: the receipt says both parties reported this digest. It does not say DocButterfly checked the file, because DocButterfly never had the file. That is the honest claim, and it is the only one we make.

Read this before you rely on it

This is a working proof of concept and it behaves like one.

• Both people have to be there. A data channel is a live session, not an inbox. You and the person receiving are both signed in and on the page at the same moment.
• STUN only, no relay. Behind a symmetric NAT or a strict corporate firewall the connection fails and says so, rather than quietly routing your file through a middleman.
• The receipt covers transfers up to 2048 MB. The 556 MB run above arrived intact, and it was too big to be witnessed — no receipt was written for it, and the page said so at the time.

Why a document platform ships a file transfer

Because the file is rarely the end of the job. Once it lands, the same account will convert it, read it, pull the fields out of it, get it signed, file it in a vault you control, or hand it to a workflow that does all five — from the portal or from your own code over a REST API. See the rest of it.