# How WebRTC file transfer works

Source: https://help.strongfolder.com/en/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> WebRTC file transfer works in three phases. A signaling server introduces two browsers; STUN and ICE find a network path through home routers (NAT), falling back to a TURN relay if no direct path exists; then the browsers open a DTLS-encrypted data channel and stream the file in chunks, directly or through the relay, without storing it.

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.

**Key facts**

- **WebRTC** is a browser standard for direct, encrypted connections between two devices; file tools use its **data channels**.
- **Signaling** introduces the browsers; **STUN** and **ICE** find a path through routers (**NAT**); a **TURN relay** forwards traffic when no direct path exists.
- **Encryption:** every data channel uses **DTLS** — WebRTC has no unencrypted mode.
- StrongFolder uses PeerJS on top of WebRTC, a StrongFolder signaling server, public STUN servers (including Google's) and its own TURN relays. Files are never uploaded to or stored on a StrongFolder server.
- The file streams in chunks from the sender's disk to the recipient's disk; the sender stays online.

## What is WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) 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](https://help.strongfolder.com/en/glossary/#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:

1. They don't know **how to reach each other** — neither knows the other exists.
2. They don't know **their own public address** — only the private one, like 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/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.

[Send files now](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/) and
[Security & privacy](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) and
[How StrongFolder works](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### What is a WebRTC data channel?

A data channel is the part of WebRTC that carries arbitrary bytes between two browsers instead of audio or video. It runs SCTP over DTLS over UDP, so it is encrypted and can be configured as reliable and ordered — which is what file transfer needs.

### What is the difference between STUN and TURN?

A STUN server only tells a browser what its public address looks like, so the two browsers can try to connect directly; no file data passes through it. A TURN server is a relay: when no direct path works, the encrypted stream goes through it. StrongFolder runs its own TURN relays, which forward and do not store data.

### Does the signaling server see my files?

No. The signaling server passes only connection messages — session descriptions and network candidates — between the browsers. File data flows over the data channel, either directly or through a TURN relay.

### Is WebRTC file transfer encrypted?

WebRTC encrypts every data channel with DTLS, so the file stream is encrypted in transit on every connection. WebRTC does not allow unencrypted data channels. The keys are negotiated by the two browsers; their fingerprints travel through signaling, which is why this is encryption in transit rather than end-to-end encryption with keys you manage.

### Why does a WebRTC transfer sometimes fail or stay slow?

Usually because of the network path: a strict firewall or VPN blocks direct UDP, so the connection falls back to a TURN relay over TCP, or cannot connect at all. Try another network (for example a phone hotspot), turn off the VPN, or ask IT to allow WebRTC.

### Can a TURN relay read my files?

The relay forwards DTLS-encrypted packets between the two browsers. It sees encrypted traffic, sizes and timing, not the file content, and StrongFolder's relay does not store what it forwards.