Browser-based device-to-device transfer uses WebRTC, a technology built into modern browsers that lets two devices open an encrypted connection directly to each other. A small server helps the devices find each other (signalling), a STUN server helps them discover how they appear on the internet, and if a direct path is impossible a TURN server relays the encrypted data between them. The file itself is split into chunks and sent over a WebRTC data channel, encrypted in transit with DTLS.
This guide walks through each piece in the order it happens, what each server can and cannot see, and why transfers sometimes fail.
The problem WebRTC solves
Most devices do not have a public address that another device can connect to. Your phone and laptop sit behind a home router, a mobile network or an office firewall that uses NAT (network address translation): many devices share one public IP address, and the router only lets incoming traffic through when it matches a conversation started from the inside.
The traditional answer is to upload the file to a server and let the other device download it. That works everywhere, but the server stores a copy, both ends need to wait for two full transfers, and the operator can see the data unless it is encrypted separately.
WebRTC takes a different approach: get the two browsers talking directly whenever the network allows it, and fall back to a relay only when it does not.
Step 1: Signalling
Before two browsers can connect, they need to exchange some setup information. WebRTC deliberately does not define how this happens; each application chooses its own signalling method, commonly a WebSocket connection to its own server.
Two kinds of message pass through the signalling channel:
- Session descriptions (SDP): an "offer" from one device and an "answer" from the other, describing what the connection will carry and including a fingerprint of each side's encryption certificate.
- ICE candidates: the possible network addresses at which each device might be reachable.
The file itself does not go through the signalling server. Its job is introductions only. This is why browser transfer tools usually use a short code, QR code or room link: it is how the signalling server knows which two devices to introduce.
Step 2: Finding a route with ICE, STUN and TURN
ICE (Interactive Connectivity Establishment) is the process of gathering possible addresses and testing them in pairs until one works. There are three kinds of candidate:
| Candidate type | Where it comes from | What it means |
|---|---|---|
| Host | The device's own network interface | Works when both devices are on the same local network |
| Server-reflexive | A STUN server | The public address and port the router is using for this device |
| Relay | A TURN server | An address on a relay server that forwards traffic |
STUN
A STUN server is simple and cheap to run. The browser sends it a request, and the server replies with the public IP address and port it saw. The browser now knows how it looks from the outside and can share that as a candidate. STUN does not carry any file data.
Many modern browsers hide a device's local IP address in host candidates by replacing it with a random .local name (mDNS), which reduces what a web page can learn about your local network.
NAT traversal
With both devices' public candidates exchanged, each sends packets towards the other at the same time. Many routers then treat the incoming packets as replies to an outgoing conversation and let them through. This technique, often called hole punching, is what makes a direct connection possible between two devices on different networks.
It does not always work. Some routers, carrier-grade NAT on mobile networks and strict corporate firewalls allocate ports in ways that make the address learned via STUN useless to the other peer, or block UDP entirely.
TURN
When no direct route works, TURN steps in. Both devices connect outwards to a TURN server, which forwards packets between them. TURN can run over UDP, TCP or TLS, which helps it get through restrictive firewalls.
Relaying costs bandwidth, so TURN servers are expensive to run and are usually protected with credentials. Relayed transfers are also typically slower than direct ones, because every byte travels to the relay and back out again.
Step 3: The encrypted connection
Once ICE finds a working pair of addresses, the browsers perform a DTLS handshake (DTLS is essentially TLS adapted for UDP). Each side checks that the certificate presented matches the fingerprint it received in the SDP.
Encryption is mandatory in WebRTC; there is no unencrypted mode. For file transfer, data travels over an RTCDataChannel, which runs SCTP on top of DTLS. Audio and video use SRTP, keyed from the same DTLS handshake.
Importantly, a TURN relay only forwards the encrypted packets. The keys are negotiated between the two browsers, so the relay cannot read the file contents. It can see metadata such as the IP addresses involved, the timing and the amount of data.
Step 4: Sending the file in chunks
A data channel sends messages, not files, and very large messages are not reliably supported across browsers. So transfer tools read the file in chunks, commonly somewhere around 16–64 KiB, and send them one after another. The receiver reassembles them in order.
The sender must also avoid flooding the channel. The browser exposes bufferedAmount so the sending code can pause when too much is queued and resume when the buffer drains:
const CHUNK = 64 * 1024;
channel.bufferedAmountLowThreshold = 1024 * 1024;
async function sendFile(file) {
for (let offset = 0; offset < file.size; offset += CHUNK) {
if (channel.bufferedAmount > 8 * 1024 * 1024) {
await new Promise(r =>
channel.addEventListener('bufferedamountlow', r, { once: true }));
}
const buf = await file.slice(offset, offset + CHUNK).arrayBuffer();
channel.send(buf);
}
}
On the receiving side, holding a multi-gigabyte file entirely in memory can crash a tab, especially on a phone. Better tools write chunks to disk as they arrive, using browser storage or streaming download techniques, where the browser supports them.
What each party can see
| Party | Can see the file contents? | Can see |
|---|---|---|
| Signalling server | No (the file never passes through it) | That two devices connected, their IP addresses, SDP including certificate fingerprints, and anything else the app chooses to send |
| STUN server | No | Your public IP address and port |
| TURN relay | No, data is DTLS-encrypted | IP addresses, timing and volume of traffic |
| The other device | Yes, that is the point | Your public IP address (unless relayed) and the file |
There is one important caveat. Because fingerprints are exchanged over the signalling channel, a malicious or compromised signalling server could substitute its own and sit in the middle. In practice you are trusting the site that runs the signalling server, and the web page code running on both ends, which could in principle read the file before it is encrypted. Choose tools from operators you trust, served over HTTPS.
Server-relay fallbacks
Not every "browser transfer" tool is purely WebRTC. Some fall back to uploading through their own server when a peer connection fails, using an ordinary HTTPS upload or WebSocket. In that case the connection to the server is encrypted with TLS, but the server can see the data unless the app adds its own end-to-end encryption on top. A trustworthy tool will tell you which mode it is using.
Why transfers fail, and what helps
- Phone screen locks or the tab goes into the background. Mobile browsers suspend background tabs, which drops the connection. Keep the tab open and the screen on.
- Strict network. Office, school and some public Wi-Fi networks block UDP. A tool with a TURN server over TCP or TLS will cope better.
- Out of memory on large files. Use a tool that streams to disk, or split the job into smaller files.
- Mobile data. Carrier-grade NAT often forces relaying, which is slower.
If you mainly need to move footage from your own phone to your own computer, compare this with the options in sending large files from phone to PC. For privacy considerations with client work, see protecting client footage, and for the same "does it leave my device?" question applied to transcription, see local vs cloud transcription.
The full API is specified by the W3C in >WebRTC: Real-Time Communication in Browsers.
Key takeaways
- Signalling introduces the devices; the file does not pass through it.
- STUN tells a device its public address; TURN relays traffic when direct connection fails.
- All WebRTC data is encrypted with DTLS; a TURN relay cannot read it.
- You still trust the site that serves the page and runs signalling.
- Keep both screens awake for large transfers.
FAQ
Is WebRTC file transfer end-to-end encrypted?
Data is encrypted between the two browsers, and relays cannot read it. The keys are verified using fingerprints exchanged via the signalling server, so you are trusting that server and the page's code not to interfere.
Does the other person see my IP address?
On a direct connection, yes, the other device sees your public IP address. When traffic is relayed through TURN, the peer sees the relay's address instead.
Why is my transfer much slower on mobile data?
Mobile networks often use carrier-grade NAT, which can prevent a direct connection. The transfer then goes through a TURN relay, adding distance and a bandwidth limit.
Do both devices need to be on the same Wi-Fi?
No. Being on the same network gives the fastest direct route, but STUN and TURN allow transfers across different networks.