WebRTC (Web Real-Time Communication) is an open standard, built into every major browser, that lets two devices open an encrypted connection to each other and exchange audio, video or arbitrary data without installing anything. For file transfer, the relevant part is the data channel: an encrypted pipe between two browser tabs that carries bytes over SCTP, inside DTLS, over UDP. A server is still needed to introduce the two browsers, and sometimes to relay traffic when routers block a direct path, but the file itself does not have to be uploaded and stored anywhere.
The rest of this guide explains each moving part in the order a real connection uses them, and what each one implies for you as a user.
Where WebRTC came from
The technology started inside Google. In 2010 Google bought Global IP Solutions, a company whose voice and video engine (codecs, echo cancellation, jitter buffers) had been licensed to many VoIP products. In May 2011 Google released that engine as an open-source project and proposed a browser API around it. Two standards bodies then split the work: the W3C defined the JavaScript API that web pages call (RTCPeerConnection, RTCDataChannel and friends), and the IETF defined the network protocols underneath.
Browser support arrived in stages. Chrome and Firefox implemented early versions, and Apple added WebRTC to Safari 11 in 2017, which was the moment it became practical on iPhones. On 26 January 2021 the W3C and IETF jointly announced that WebRTC was an official standard, with WebRTC 1.0 becoming a W3C Recommendation and the core IETF documents published as a batch of RFCs, including RFC 8825 (the overview), RFC 8827 (security) and RFC 8831 (data channels). The W3C has since published updated Recommendations that fold in amendments, most recently in March 2025.
The protocol stack, layer by layer
A WebRTC data channel is several protocols stacked on top of each other. Each layer solves one problem.
| Layer | Protocol | What it does for a file transfer |
|---|---|---|
| Application | RTCDataChannel API | The page calls send() with chunks of the file and receives them in a message event on the other side. |
| Message transport | SCTP | Splits messages into packets, retransmits lost ones, keeps them in order, and applies congestion control so the transfer backs off on a busy network. |
| Security | DTLS | The datagram version of TLS. Authenticates the peers' keys and encrypts everything. Mandatory: the WebRTC security architecture (RFC 8827) says all data channels must be secured with DTLS. |
| Path finding | ICE (with STUN and TURN) | Discovers which network route between the two devices actually works. |
| Transport | UDP (TCP as a fallback) | Carries the packets. UDP is preferred because WebRTC handles reliability itself in SCTP. |
RFC 8831, which defines data channels, notes that each message can be sent ordered or unordered, and with full or partial reliability. File transfer apps use the reliable, ordered mode, because a single missing or misplaced chunk would corrupt the file. Video calls, by contrast, often prefer to drop late packets rather than wait for them.
Signaling: the introduction nobody standardised
Before two browsers can talk, each needs to know the other's capabilities, encryption fingerprints and possible network addresses. These are packaged as an offer and an answer in a text format called SDP, plus a stream of ICE candidates (possible addresses). WebRTC deliberately does not specify how this information travels. An app can use a WebSocket server, an HTTP API, or even copy and paste.
That is why every WebRTC app runs some kind of signaling or "broker" server. Its job is short: pass the offer, answer and candidates between the two browsers, then step aside. It never needs to see the file. It does, however, see metadata such as when two peers connected and their IP addresses, and RFC 8827 is candid that a malicious signaling server could in principle attempt a man-in-the-middle attack by substituting its own keys. In practice you are trusting the app's operator not to do that, which is the same trust you place in the operator of any web service you load.
Getting through routers: ICE, STUN and TURN
Most devices sit behind NAT (network address translation). Your laptop has a private address like 192.168.1.20; the router shares one public address among everyone on the network and keeps a table of which outgoing connection belongs to which device. That table is the obstacle. A packet arriving from a stranger on the internet has no matching entry, so the router drops it.
ICE (Interactive Connectivity Establishment, RFC 8445) solves this by collecting every address that might work and then testing pairs of them. There are three main kinds of candidate:
- Host candidates: the device's own local addresses. These work when both devices are on the same network.
- Server-reflexive candidates: the public address and port the router assigned, learned by asking a STUN server "what address do you see me coming from?"
- Relayed candidates: an address on a TURN server that will forward traffic on the device's behalf.
Both browsers then send STUN connectivity checks across candidate pairs at the same time. When each side sends outward, each router creates a table entry, and packets from the other side can now get in. This is often called hole punching. ICE prioritises direct routes: host candidates rank highest and relayed candidates lowest, so a relay is only used when nothing better works.
Why some networks need a relay
Hole punching relies on the router reusing the same public port for a device regardless of who it is talking to. RFC 4787 calls this endpoint-independent mapping and makes it a requirement for well-behaved NATs. Some routers, common on corporate networks and some mobile carriers, instead allocate a different public port for every destination. This behaviour is widely known as symmetric NAT (the RFCs prefer "address and port-dependent mapping"). The port your STUN server observed is then useless to your peer, because the router will assign yet another port when you talk to the peer, and will only accept replies from addresses you have already contacted.
When one or both sides are behind that kind of NAT, or a firewall blocks UDP outright, the only option is TURN (RFC 8656). The TURN server sits on the public internet, both browsers connect out to it, and it forwards packets between them. MDN's WebRTC protocol guide describes TURN as the way to bypass the symmetric NAT restriction, at the cost of extra overhead. RFC 4787 is blunter: failure to support endpoint-independent mapping "will force the use of a UDP relay."
What servers can and cannot see
Because encryption is negotiated end to end between the browsers, the servers involved learn surprisingly little about the content. This table summarises a typical data-channel file transfer.
| Party | Can see | Cannot see |
|---|---|---|
| Signaling server | That two peers connected, when, their IP addresses, the SDP (including key fingerprints) | File contents, which never pass through it |
| STUN server | Your public IP address and port at the moment you ask | Anything about the transfer |
| TURN relay (if used) | Both IP addresses, timing, total bytes forwarded | File contents or file names: it forwards DTLS-encrypted packets without the keys |
| Your network operator | That you exchanged encrypted UDP traffic with an address, and how much | File contents |
One practical implication: a peer-to-peer connection reveals each side's IP address to the other, since that is how a direct path works. If that matters to you, a service that routes everything through its own servers hides addresses from the other party but means trusting that service with the data instead.
Our tool is a WebRTC data-channel app built on the open-source PeerJS library. The public PeerJS broker handles signaling. When a direct path is impossible, traffic is relayed through Metered's Open Relay TURN service; it stays DTLS-encrypted, so the relay cannot read it, but in that case it does pass through a relay. Files are never stored on a server. The how it works page walks through a session step by step.
Why both tabs have to stay open
A WebRTC connection lives inside the web page that created it. There is no background service and no server-side copy of the file. Close the tab, navigate away, or let the operating system suspend it, and the RTCPeerConnection is torn down. The other side sees the connection drop.
Phones make this especially easy to trigger. Mobile operating systems aggressively pause pages that are not in the foreground to save battery, and a locked screen can have the same effect. That is why live peer-to-peer tools ask both people to keep the page visible and the device awake until the transfer finishes. It is also why "send now, they collect it tomorrow" is a job for a cloud upload service, not WebRTC: there is nowhere for the file to wait. Our peer-to-peer file sharing guide covers that trade-off in more depth.
Backpressure: why apps watch bufferedAmount
Reading a file from disk is much faster than most network uploads. If a page simply looped over a 5 GB file calling send() on every chunk, it would pile data into the browser's outgoing queue faster than the network could drain it. The data channel exposes that queue size as bufferedAmount, which MDN defines as the number of bytes queued to be sent. If the queue has no room left, send() throws an OperationError, according to MDN's reference for the method.
Well-written transfer code therefore applies backpressure:
- Set
bufferedAmountLowThresholdto a modest value. - Send chunks while
bufferedAmountstays under a chosen ceiling. - Pause, and resume when the browser fires the
bufferedamountlowevent, which it does when the queue drains to the threshold.
The receiving side has a mirror-image problem. It has to put incoming chunks somewhere. Browsers that support writing straight to a file on disk can stream them out as they arrive; others have to hold the whole file in memory until it is complete. That is the main reason very large files can fail on phones or low-memory machines even when the network is fine.
Strengths and limits in one list
- Encrypted by default. DTLS cannot be switched off in a standards-compliant browser.
- No storage step. Data goes straight from one device to the other, so there is no upload-then-download wait and no copy left on a server.
- Speed is set by the two endpoints. The transfer runs at roughly the slower of the sender's upload and the receiver's download, minus any relay bottleneck. The transfer time calculator gives a realistic estimate.
- Live only. Both devices must be online at the same time.
- Network-sensitive. Strict firewalls, UDP blocking and some VPNs can force a relay or prevent connection entirely. See why file transfers get blocked on some networks for diagnosis.
Sources
- W3C and IETF press release: WebRTC is now an official standard (26 January 2021)
- W3C: WebRTC Recommendation
- RFC 8831: WebRTC Data Channels
- RFC 8827: WebRTC Security Architecture
- RFC 8445: Interactive Connectivity Establishment (ICE)
- RFC 8656: Traversal Using Relays around NAT (TURN)
- RFC 4787: NAT Behavioral Requirements for Unicast UDP
- MDN: Introduction to WebRTC protocols
- MDN: RTCDataChannel.bufferedAmount
- MDN: RTCDataChannel.send()
- Wikipedia: WebRTC (history and browser support)
Need to send a file right now?
TransferFiles.net sends files of any size straight from your browser to theirs. Free, no account, nothing stored.
Frequently asked questions
It is a standard. The browser API is specified by the W3C and the underlying protocols by the IETF, and every major desktop and mobile browser ships an implementation. Many different apps and sites build on it.
Yes, at least briefly. A signaling server is needed so the two browsers can exchange connection details, and STUN or TURN servers help them get through routers. Once connected, data usually flows directly between the devices unless a TURN relay is required.
Not in a standard WebRTC data channel. The relay forwards packets that are already encrypted with DTLS keys negotiated between the two browsers, so it sees encrypted bytes, IP addresses and traffic volume, not file contents.
The transfer can only go as fast as the slower side: the sender's upload speed or the receiver's download speed. A relay, Wi-Fi congestion or a phone throttling a background tab can also cut throughput.
In Chrome or Edge, open chrome://webrtc-internals (edge://webrtc-internals in Edge) before connecting, then look at the selected candidate pair. A candidate type of relay means traffic is going through a TURN server. Firefox offers similar information at about:webrtc.
Related guides
Peer-to-peer file sharing: how it works and which kind to use
Browser P2P, local-network apps and BitTorrent compared: how each connects, what it is good at, and the legal basics.
GuidesFile transfer blocked or slow on this network? How to diagnose and fix it
A symptom-by-symptom guide to transfers that fail on corporate, school, hotel and public Wi-Fi or behind a VPN.