WebRTC file transfer, explained

By the WispFile team · Updated 24 September 2026

WebRTC file transfer sends a file directly from one browser to another over an encrypted data channel. A signaling server introduces the two browsers, STUN helps them find a network path through routers, and, if no direct path exists, a TURN server relays the encrypted bytes. The file is split into chunks, sent in order with flow control, and reassembled on the other side.

The four parts of a WebRTC transfer

1. Signaling: introducing the browsers

Two browsers cannot find each other on their own. Each one creates a description of how it can connect (an SDP offer or answer) and a list of possible network addresses (ICE candidates). Something has to pass these between them. WebRTC leaves that to the application; WispFile uses a small WebSocket service. It sees that two browsers want to talk, forwards their messages, and never sees the file.

2. NAT traversal: STUN and TURN

Most devices sit behind a router that shares one public address between many devices (NAT). A STUN server answers a simple question: “what address do you see me coming from?” With that, the browsers try to reach each other through their routers, a process called ICE (Interactive Connectivity Establishment, RFC 8445).

When both sides are behind restrictive NATs or firewalls, no direct path works. A TURN server (RFC 8656) then relays the traffic. It passes along encrypted bytes it cannot read, but it does cost bandwidth, which is why many services limit it. On WispFile, free links are direct only and paid plans include a relay.

3. The data channel

Once connected, the browsers open an RTCDataChannel, a message pipe built on SCTP over DTLS. It can be ordered and reliable like TCP, which is what file transfer needs. Two practical details matter:

• Message size. Browsers cap a single message; the connection advertises its limit (maxMessageSize). WispFile sends files in 256 KB frames and checks the peer’s limit before the first one.
• Backpressure. A sender that pushes chunks as fast as it can read them fills memory with queued data. The fix is to watch bufferedAmount and wait for the bufferedamountlow event before sending more. Without it, sending a 2 GB file can mean 2 GB of queued messages.

4. Writing to disk on the other side

A received file must not be collected in memory either. Chromium browsers can write straight into a file or folder the user picks (the File System Access API). Other browsers can stream a download through a service worker. Either way, each chunk is written as it arrives, which is what makes multi-gigabyte transfers possible in a browser tab.

Encryption: what DTLS covers and what it does not

DTLS encrypts the data channel between the two endpoints of the connection. If a TURN relay carries the traffic, the relay forwards encrypted packets it cannot read. What DTLS does not protect against is a malicious signaling server, which could in principle introduce itself as the other peer. WispFile closes that gap with a second layer: every chunk is encrypted with AES-GCM under a 256-bit key created in the sender’s browser and placed in the link’s fragment (after the #), which browsers never send to a server. Each chunk also carries a SHA-256 fingerprint that the receiver checks before writing.

What goes wrong, and how to handle it

Try it

WispFile is a WebRTC file transfer tool built this way. Open it in two browsers, on two networks if you can, and watch a file cross without being uploaded. For the product-level view, see how WispFile works; for the standard itself, MDN’s WebRTC API documentation and the W3C WebRTC specification.

Frequently asked questions

Related guides

• Browser-to-browser file sharing — Sharing with nothing to install on either side.
• Peer-to-peer file sharing: how it works and when it’s safe — P2P without the torrent baggage: what it is and what makes it safe.
• End-to-end encrypted file transfer — Who holds the key decides who can read the file.