WebRTC file transfer lets two browsers send a file to each other without uploading it to cloud storage. It sounds simple, but the internet was not built for two home computers to call each other directly. This guide walks through what actually happens — signaling, NAT, STUN, ICE, TURN, DTLS and data channels — in plain language, using StrongFolder as the example.
What is WebRTC?
WebRTC (Web Real-Time Communication) is a set of browser APIs and network protocols, standardised by the W3C and the IETF, for real-time connections between browsers. Chrome, Edge, Firefox, Safari and Opera all support it. It was built for video and voice calls, but it also has data channels that carry any binary data — which is exactly what a file is.
The key property: once a WebRTC connection is set up, data goes between the two endpoints, not into a server's storage. That is what makes P2P file transfer in the browser possible.
Why can't two browsers just connect to each other?
Because almost no device has its own public address. Your laptop sits behind a home router, an office firewall or a mobile carrier's network. The router performs NAT (Network Address Translation): many private devices share one public IP address, and the router only lets in traffic that answers something sent from inside.
So two browsers face three problems before any file data can flow:
- They don't know how to reach each other — neither knows the other exists.
- They don't know their own public address — only the private one, like 192.168.1.20.
- Their routers may block unsolicited incoming traffic.
WebRTC solves each problem with a separate mechanism.
How does a WebRTC file transfer work, step by step?
Here is the full flow, from clicking "share" to the last byte:
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Step 1–2 — Signaling. The sender picks files; the service records the metadata needed for the link. When the recipient opens the link, both browsers are connected to a signaling server. WebRTC does not define how signaling works; StrongFolder uses PeerJS with its own signaling server.
Step 3 — Offer and answer. One browser creates an offer in SDP (Session Description Protocol): "I want a data channel, here are my encryption fingerprint and capabilities." The other replies with an answer. Both travel through the signaling server.
Step 4 — STUN. Each browser asks a STUN server, "what address and port do you see me coming from?" The answer is its public address as mapped by the router. STUN servers handle a tiny request and no file data; StrongFolder uses public STUN servers, including Google's, and its own.
Step 5 — ICE candidates. Each browser collects candidates — possible ways to reach it: its local network address (host), its public address from STUN (server-reflexive) and an address on a TURN relay (relayed). They swap candidates via signaling.
Step 6 — Connectivity checks. ICE (Interactive Connectivity Establishment) tests candidate pairs and picks the best one that works. If both devices are on the same Wi-Fi, a local path wins. If routers allow it, a direct internet path ("hole punching") wins. If nothing direct works, the relayed path is used.
Step 7 — DTLS. Before any data flows, the browsers run a DTLS handshake (TLS adapted for UDP) and check that the certificate fingerprints match those in the offer and answer. From now on everything is encrypted.
Step 8 — Data channel. Over DTLS runs SCTP, which gives the data channel reliable, ordered delivery. In StrongFolder the recipient's browser requests a file, the sender's browser reads it from disk in chunks and sends them, and the recipient writes each chunk to disk as it arrives — so even very large files never have to fit in memory.
What do STUN, TURN, ICE and the other terms mean?
| Term | What it does | Sees file data? | Standard |
|---|---|---|---|
| Signaling | Passes offers, answers and candidates between browsers | No | Not standardised (app-specific) |
| NAT | Router feature that shares one public IP among many devices | — | — |
| STUN | Tells a browser its public address and port | No | IETF RFC 8489 |
| ICE | Collects candidates and picks a working path | No | IETF RFC 8445 |
| TURN | Relays traffic when no direct path works | Encrypted packets only | IETF RFC 8656 |
| DTLS | Encrypts the connection (TLS for UDP) | Encrypts it | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP data channel | Reliable, ordered delivery of chunks | Carries it (encrypted) | IETF RFC 8831 |
All of these are explained briefly in the glossary.
When is a TURN relay used, and what does it see?
A relay is the fallback, not the default. ICE uses it only when no direct candidate pair connects — typically on networks with symmetric NAT (some mobile carriers), corporate firewalls that block outbound UDP, or certain VPNs.
If a direct connection is impossible (strict corporate firewall, some mobile networks), the encrypted stream passes through a StrongFolder relay (TURN) server. The relay forwards the data and does not store it.
The relay receives DTLS-encrypted packets and passes them on. It can see that traffic flows, how much and when — not what is inside. A relayed transfer can be slower than a direct one, because every byte makes an extra trip through the relay. If a transfer is unusually slow, try a different network: a phone hotspot or home Wi-Fi often connects directly where an office network does not.
Free · in your browser · no sign-up
How secure is WebRTC encryption?
WebRTC makes encryption mandatory: there is no way to open an unencrypted data channel. DTLS uses modern ciphers negotiated by the two browsers, and fresh keys are created for each connection.
There is one honest caveat that applies to every WebRTC service. The two browsers verify each other through certificate fingerprints that are exchanged via the signaling server. You therefore trust the service's signaling not to tamper with them. That is why StrongFolder describes its protection as encryption in transit — not as end-to-end encryption with keys you hold, and not as "zero-knowledge". For a broader view of what "secure" means, read Secure file sharing and Security & privacy.
Why must the sender's browser stay open?
Because the sender's browser is the source. There is no server copy to fall back on: the data channel reads chunks from the sender's disk only while the tab is open and the device is awake. The sender's browser tab must stay open and online until the recipient finishes downloading — files come from the sender's device, not from a server. How to plan for that is covered in Why the sender stays online.
How fast is WebRTC file transfer?
There is no fixed speed. The ceiling is the slowest link on the path: usually the sender's upload speed. As a rule of thumb, 1 GB takes about 2.7 minutes at 50 Mbit/s, about 80 seconds at 100 Mbit/s, and well under a minute on a fast local network. Real transfers run somewhat below these numbers because of protocol overhead, disk speed and, with a relay, the extra hop. One link can be opened by several recipients; each downloads directly from the sender. Several downloads at once share the sender's upload.
Summary
A WebRTC file transfer is a short negotiation followed by a long, encrypted stream: signaling introduces the browsers, STUN and ICE find a path through NAT, TURN relays as a last resort, and DTLS-encrypted data channels carry the file from disk to disk. For the practical side — what this means for you as a sender — start with P2P file transfer in the browser and How StrongFolder works.