How Browser-to-Browser File Transfer Actually Works
A plain-language walkthrough of WebRTC data channels: how two browsers find each other, negotiate an encrypted link, and move file bytes without a server in the middle.
When you send a file with a cloud service, the file makes two trips: up to a data center, then down to the recipient. Browser-to-browser transfer removes the middle stop. Two browsers negotiate a direct, encrypted channel and the bytes flow between them. The technology that makes this possible in every modern browser is WebRTC — specifically a part of it called the data channel.
The three jobs that need doing
Any browser-to-browser transfer has to solve three separate problems:
- Introduction. Two browsers that have never met need to exchange connection details. They cannot talk to each other yet — so a small “signaling” server relays their introduction messages. Crucially, this server only carries negotiation metadata, never file content.
- Path finding. Both devices usually sit behind home routers (NAT) that do not accept unsolicited incoming traffic. WebRTC's ICE machinery gathers every plausible network path and tests them pair by pair until one works — local network, across the internet, or through a relay as a last resort. (More in STUN, TURN and ICE explained.)
- Reliable, encrypted delivery. Once a path exists, the data channel gives you an encrypted (DTLS) and — in the configuration ShareDrop.org uses — reliable, ordered byte pipe, similar to TCP but running peer-to-peer.
Why files need more than a raw pipe
A data channel moves messages, not files. A real transfer protocol has to be layered on top, and this is where implementations differ enormously. ShareDrop.org's protocol does the following, and any serious implementation needs equivalents:
- A manifest first. The receiver sees file names, sizes and types and explicitly accepts before a single content byte is sent.
- Chunking. Files are cut into 64 KiB pieces. Browsers limit individual message sizes, and chunks give you progress reporting and resumability.
- Backpressure. Reading a fast disk into a slower network link will balloon memory until the tab dies. The sender watches the channel's buffered amount and pauses reading when a high-water mark (8 MiB in our case) is reached. This single detail separates demos from tools that survive real files — see large files in the browser.
- Integrity checking. Both sides hash the file with SHA-256 while it streams. Only matching hashes count as success (details).
What the servers never learn
In this architecture the signaling server learns that two anonymous browsers connected and exchanged negotiation messages. It does not learn file names, sizes or contents — those travel only inside the encrypted channel. Even when a relay must forward the traffic, it forwards ciphertext: the encryption keys were negotiated directly between the two browsers (how that works).
The honest caveats
- Both browsers must stay open for the duration — there is no store-and-forward.
- Some networks make direct connection impossible; a relay adds a hop (still encrypted), and a network that blocks even relay ports blocks the transfer.
- The receiving device ends up with a copy of the file. Encryption in transit says nothing about what happens after arrival.
Those trade-offs are inherent to the model, not bugs. In exchange you get transfers with no upload step, no storage to breach later, and no account to create.