Skip to main content
How it works

Peer-to-peer file transfer in your browser, explained.

Volo does peer-to-peer file transfer in the browser: two tabs connect to each other with WebRTC and the file flows between them, not through a file server. This page walks through each part of that connection, what it protects, and where its limits are.

Free · No sign-up · Files aren't uploaded or stored

The pipe: a WebRTC data channel

WebRTC is built into modern browsers for real-time connections between devices. Volo uses the PeerJS library to open a reliable, ordered data channel between the two browsers and sends everything over it: file chunks, shared text, accept and decline replies, and a small heartbeat.

Signaling: how two browsers find each other

Before two browsers can connect, they have to exchange a connection offer and answer (SDP) and the network routes each might be reachable on (ICE candidates). Volo uses the public PeerJS signaling server for this. The first device registers under the room code, the second registers under the room code plus "-guest", and the server passes their connection messages back and forth.

Once the data channel is open, file data doesn't pass through the signaling server. The server does see the room code and connection details such as IP addresses, never file contents.

See also:

STUN, and why there's no relay

Most devices sit behind a router that hides their real address. Volo gives WebRTC two Google STUN servers, which tell each device the public address it appears from, so the browsers can try to reach each other directly. That often works across different networks; same Wi-Fi is most reliable.

When no direct path exists, WebRTC apps usually fall back to a TURN relay that forwards the traffic. Volo doesn't run one today. The consequence is that some network pairs, such as strict NAT or some corporate and mobile networks, can't connect at all, rather than being routed through a server.

Encryption: in transit, not end-to-end

Everything on the data channel is encrypted in transit with DTLS, WebRTC's built-in transport encryption. Someone watching the network between the two devices sees encrypted traffic.

Volo doesn't add a separate end-to-end encryption layer. Each browser checks the other's DTLS key against a fingerprint exchanged during signaling, so the arrangement depends on the signaling server relaying those messages faithfully. That's the standard WebRTC trust model, and it's worth knowing if your threat model includes the signaling path.

See also:

Chunking, backpressure and saving to disk

The sender reads the file 256KB at a time with file.slice() and sends each piece in turn. Before each send it checks the data channel's bufferedAmount, and if about 2MB is already waiting it pauses until the buffer drains. The whole file is never loaded into memory.

The receiver has two modes. In desktop Chrome and Edge it uses the File System Access API to write each chunk straight into the file you chose, and asks the sender to pause if more than 8MB is waiting to be written. Other browsers collect the chunks in memory and assemble the file when the last one arrives, which is why they're capped at 1GB.

See also:

Why both devices must stay online

No server holds a copy, so the file only exists in transit while both tabs are open. Nothing is sent until the receiver sees the file's name and size and clicks Accept.

Each side sends a heartbeat every 3 seconds. If nothing arrives for about 12 seconds, the other device is treated as gone, the transfer stops, and a partly written file is abandoned. Volo doesn't reconnect or resume, so the file has to be sent again. On phones, screen lock or backgrounding can cause this; Volo requests a screen wake lock during transfers where the browser supports it.

Browser and network requirements

  • A modern WebRTC-capable browser with JavaScript enabled on both devices.
  • For receiving files over 1GB: Chrome or Edge on a desktop computer.
  • Networks that allow a direct WebRTC connection between the two devices.
  • Rooms are for exactly two devices; a third is told the room is full.

Troubleshooting

Stuck on Waiting for peer

The second device hasn't joined yet. Check it opened the same link or typed the same room code, and that the first device's tab is still open.

The devices never finish connecting, or the room shows Error

Signaling may have worked while WebRTC found no direct route, which is the case a relay would cover. Put both devices on the same Wi-Fi, or move one off a restrictive corporate network. Browser settings or extensions that restrict WebRTC can also block the connection.

A transfer stopped at a random point

One side lost contact for about 12 seconds, usually through sleep, a closed tab or a network change. Keep both devices awake and on power, then send the file again.

Frequently asked questions

Does Volo add its own encryption on top of WebRTC?

No. Data is encrypted in transit with DTLS, WebRTC's built-in transport encryption, but Volo doesn't add its own end-to-end layer, and key verification relies on messages passed through the signaling server.

Can the signaling server see my files?

No. It sees the room code and connection details such as IP addresses, never file contents. File data flows over the data channel directly between the two browsers.

Does the other device see my IP address?

Usually, yes. A direct WebRTC connection works by the two devices exchanging the network addresses they can be reached on, which can include local and public IP addresses.

Why doesn't Volo relay the file when a direct connection fails?

Volo doesn't operate a TURN relay today, so there's nothing to fall back to. A relay would forward the still-encrypted traffic when no direct path exists; without one, those network pairs can't connect.

Related guides

Try it between two of your devices

Create a room here, open the link on a second device, and send a small test file to see the connection work.