How does P2P file transfer work in your browser?

P2P (peer-to-peer) file transfer sends a file straight from one device to another over a live connection, instead of uploading it to a server for someone to download later. So how does P2P file transfer work without that upload? A server introduces the two devices, WebRTC finds a path between them (direct when it can, through a relay when a network blocks it) and encrypts the connection with DTLS, then the file streams across. Here's every step, using Beamaroo's P2P file transfer as the worked example.

What is P2P file transfer?

P2P stands for peer to peer. In a P2P transfer the two devices (the peers) connect to each other and the file crosses that connection, instead of going up to a company's server and down again later. Nothing sits on a server waiting to be picked up and no copy is left behind, which is how you share files without uploading them anywhere. The catch: both devices have to be online at once.

“P2P file sharing” often means something else: BitTorrent, where many peers swap pieces of a file at once and a tracker hands out lists of other peers (BitTorrent spec). That's built for spreading a file widely, not handing one file to one person privately.

How does P2P file transfer work, step by step?

One transfer, start to finish, in Beamaroo. Other browser P2P tools work in a similar way, though pairing and confirmation differ.

1. You pick files and tap Get a code. Our server reserves a channel number and your device adds two random words, making a code like beam-7-otter-quartz. Your files haven't moved.
2. You share the code by saying it, texting it, sending the link or showing the QR code. The link carries the code after the # sign, the part of a web address browsers don't send to servers.
3. The receiver enters the code on beamaroo.com (or opens the link or scans the QR code) and taps Receive. The browsers swap connection details through our server (signalling), and WebRTC finds a route: direct if possible, through a relay if not.
4. The connection is encrypted first. WebRTC sets up DTLS between the two browsers. Then each device proves it knows the code words with a tag tied to that exact connection. A wrong code ends the session and burns the code.
5. The receiver sees the file count and total size and taps Accept. Nothing transfers before that.
6. The files stream across in encrypted chunks. As the bytes arrive, the receiving device builds an integrity hash for each file (a SHA-256 chain over its chunks) and checks it against the sender's.
7. The receipt comes back: “Delivered ✔ — verified on their device”. The code is spent, and no copy of the file exists on any server.

How WebRTC file transfer works: data channels and DTLS

WebRTC (Web Real-Time Communication) is built into modern browsers. It's what lets a web page make a video call, and it can also swap arbitrary data between two browsers with no plug-in or app (MDN). For files, that's a data channel: a two-way pipe between the devices.

Encryption is mandatory. WebRTC requires encryption for everything it carries, and data-channel traffic is secured with DTLS, which is based on the TLS behind HTTPS (MDN). The two browsers negotiate the keys, and the keys exist only on the two devices.

It's a reliable pipe. A data channel runs SCTP inside DTLS over UDP (RFC 8831) and can be set for reliable, ordered delivery, which is what a file needs: every chunk arrives, in order.

Files go in small chunks. The sending tool slices each file up and feeds the channel, pausing whenever too much is waiting to go out. The receiving browser reassembles the pieces. Beamaroo holds them in memory until each file is complete, which is why the receiving device sets the practical size limit.

Peer-to-peer file transfer over the internet: signalling, STUN and TURN

Devices on different networks can't simply call each other. Most sit behind a router that shares one public IP address (NAT), and firewalls block unexpected connections (MDN). WebRTC handles this with a signalling server for the introduction, then ICE (Interactive Connectivity Establishment), which uses STUN and TURN servers to find a route.

Signalling: the introduction

WebRTC can't open a connection without a server in the middle to pass the first messages, which MDN calls the signalling service (MDN). Each browser describes how it can be reached and which encryption fingerprint it will use. Beamaroo's server matches the two devices by the channel number in your code, passes the messages along and doesn't keep them.

STUN: finding a public address

Each browser asks a STUN server how its address looks from the internet. These possible addresses (ICE candidates) are swapped, and the browsers try them, best first, until a pair connects: locally on the same Wi-Fi, or directly across the internet when the routers allow it.

TURN: an encrypted relay when direct fails

Strict firewalls, some mobile carriers and routers using symmetric NAT (which only accept traffic from peers they've already contacted) block direct paths. Then a TURN server relays the traffic. MDN notes this adds overhead, so it's used only when nothing else works (MDN).

Beamaroo uses Cloudflare's TURN service. DTLS still runs between the two browsers, so the relay forwards bytes it can't decrypt and stores nothing. It can be slower, because every byte takes a detour.

What our server sees, and what it never sees

Beamaroo still needs a server, just not for your files.

How the pairing code and delivery receipt work

A code is the word beam, a channel number and two words from a 256-word list, like beam-7-otter-quartz, so it's easy to read across a room or over the phone. The channel number tells our server which devices to introduce. The two words are the secret, and they stay on the devices.

Once the encrypted connection is up, each side proves it holds the same words with an HMAC-SHA256 tag bound to that connection's DTLS fingerprints. A typo, a stranger trying their luck or a misrouted connection fails the check, the session aborts and the code is burnt. Codes last 30 minutes and pair one sender with one receiver, once. A download link from an upload service, by contrast, usually works for anyone who has it until it expires.

Then the receipt: the receiving browser compares each file's integrity hash with the sender's, and only a match sends “Delivered ✔” back. It proves every byte arrived intact, not that they've opened or saved the file, and it's a technical confirmation rather than legal proof of delivery.

Is P2P file transfer safe?

For sending files to people you know, yes. Many P2P warnings are really about public file-sharing networks like BitTorrent, where you download from strangers and your IP address is visible to other peers in the swarm. A one-to-one transfer is different, with its own trade-offs:

• The trip is encrypted. Every WebRTC data channel uses DTLS, and a relay only ever handles encrypted bytes.
• Nothing is left on a server. No upload means no stored copy to leak or be breached later.
• You reach the right device. Beamaroo's verified code stops wrong codes, strangers and misrouted connections, and the receiver has to tap Accept.
• Your IP address is shared. The two devices learn each other's IP addresses while connecting, as with most WebRTC tools. Beamaroo isn't anonymous, so don't swap codes with strangers.
• Encryption doesn't vet the file. Accept files only from people you trust. Beamaroo can't scan transfers for malware, because it never sees them.
• A live code is a key. Whoever enters it first gets the transfer, so give it only to your recipient. And only send what you have the right to share.

We'll never email, message or call you asking for a pairing code. Anyone who does isn't us.

Why P2P transfer speed varies

There's no fixed speed: a transfer runs at the pace of the slowest link between the two devices. That's why we don't publish speed figures. They'd describe your networks, not ours.

• Same Wi-Fi or not. On the same Wi-Fi, a direct connection runs at local network speed.
• Upload at one end, download at the other. Across the internet, a file can't leave faster than the sender's upload speed. On a home plan, that's usually the figure to check.
• Direct or relayed. A relay adds a detour, so it can be slower than a direct path.
• Signal quality. Weak Wi-Fi or patchy mobile coverage at either end slows everything down.
• A dozing browser. Phones pause locked or background browsers. Beamaroo requests a screen wake lock where supported, but switching apps can still stall a transfer.

Quickest setup: both devices on the same Wi-Fi, screens on, Beamaroo in front. Moving something big? See how to send large files.

Beamaroo's limits, and when to use something else

• Both devices must be online at once. It's a live transfer, not a locker. If someone needs the file tomorrow, an upload-and-link service is the better tool.
• One code, one receiver. It isn't built for sending to a group. For that, use an upload link, or FilePizza, which lets several people download from one link while your tab stays open.
• The receiving device's memory sets the size limit. Phones are comfortable up to a few hundred MB and computers up to about 1–2 GB, and Beamaroo warns above 300 MB on a phone or tablet, or 1.5 GB on a computer. Multi-gigabyte transfers can fail, especially in Safari on iPhone. Streaming straight to disk is planned, not built.
• Keep the screen on. Locking a phone or switching apps can stall a transfer, and there's no resume: you start a new one.
• Zip folders first. Many files at once is fine (the receiver gets a Save all button). A folder isn't, yet.
• It needs the internet, even on the same Wi-Fi, because both devices have to reach beamaroo.com to be introduced. If you'll be offline, LocalSend's app works over a local network with no internet; here's how LocalSend and Beamaroo compare.
• It isn't anonymous or open source. If you need open source, PairDrop, FilePizza and LocalSend are; our comparisons cover each one.