WebRTC Wasn't Built for File Transfer — Here's Why It Breaks Down

What WebRTC Was Actually Built For

WebRTC (Web Real-Time Communication) was created by Google and standardized by the W3C and IETF for one purpose: real-time audio and video communication in web browsers. Think video calls, screen sharing, voice chat. The entire protocol stack was designed around that use case.

The design priorities for real-time communication are fundamentally different from file transfer. In a video call, latency is everything. If a packet is lost, you don't want to wait for a retransmission—the next video frame is already on its way. A dropped frame is invisible. A 200ms delay is not. So WebRTC favors speed over reliability, and that tradeoff is baked into the architecture.

File transfer has the opposite priorities. Every byte must arrive correctly. A lost packet isn't a dropped frame you can skip—it's a corrupted file. Throughput matters more than latency. And you need to handle files that are gigabytes or hundreds of gigabytes, not a stream of small media frames.

The Data Channel Problem

WebRTC does include data channels, which let browsers send arbitrary data peer-to-peer. This is what file sharing apps use. But data channels were designed for small, real-time messages—game state updates, chat messages, cursor positions. Not bulk file transfer.

Data channels sit on top of SCTP (Stream Control Transmission Protocol), which runs over DTLS, which runs over UDP. This stack was chosen for real-time performance, not throughput. SCTP's congestion control algorithms are tuned to keep interactive streams smooth. When the network gets congested, SCTP backs off aggressively—exactly what you want for a video call, exactly what kills file transfer speed.

The result: WebRTC data channels typically top out well below what the network can actually handle. A connection that could sustain 500 Mbps for a direct TCP transfer might only push 50–100 Mbps through a WebRTC data channel because the congestion control won't let it open up.

Browser Constraints

Even if the protocol were fast, the browser environment imposes its own limits that make large file transfer painful.

Memory. Browsers handle files through JavaScript, which means the data passes through the browser's memory. For a 10 GB file, the app either needs to buffer significant chunks in RAM or use the experimental File System Access API, which has limited browser support. Many WebRTC file tools simply can't handle files beyond a few gigabytes before the browser tab crashes or the system runs out of memory.

Tab must stay open. Close the tab, the transfer dies. Navigate away, the transfer dies. Browser crashes, the transfer dies. There's no background process keeping the connection alive. You're staring at a browser tab for the duration of every transfer.

No resume. If a transfer fails—network hiccup, laptop goes to sleep, browser update—you start over from zero. Building reliable resume on top of WebRTC data channels is technically possible but extremely complex, and most browser-based tools don't implement it.

No background transfers. A native application can transfer files while you work on other things. A browser tab can't. Service workers help with some use cases but aren't designed for sustained large data transfers.

The TURN Server Reality

The biggest selling point of WebRTC-based file sharing is "peer-to-peer, no server involved." This is only half true.

WebRTC uses ICE (Interactive Connectivity Establishment) to find a path between two peers. When both peers are on simple networks, a direct connection works. But when one or both are behind symmetric NATs or restrictive firewalls—which is common in corporate networks, mobile connections, and many home routers—the direct connection fails.

When that happens, WebRTC falls back to a TURN (Traversal Using Relays around NAT) server. Your "peer-to-peer" transfer is now routed through a relay server operated by whoever built the app. Your files pass through their infrastructure. The privacy advantage disappears, and so does the speed advantage—now you're uploading to a server and the recipient is downloading from it, just like any cloud transfer service, but with worse performance because TURN adds latency and the server becomes the bottleneck.

Most WebRTC file sharing apps don't make this fallback obvious. You might think your files are going direct when they're actually transiting through someone else's server.

The Trust Problem

Browser-based tools have a fundamental trust issue that native apps don't. Every time you open a WebRTC file sharing website, your browser downloads and runs the application code from that site's server. The code can change at any time without your knowledge or consent.

Today the app might be genuinely peer-to-peer with solid encryption. Tomorrow the developer could push an update that routes everything through their servers, weakens the encryption, or adds telemetry. You'd never know—the browser loads whatever code the server sends.

A native application is installed once. You can audit the version you have. Updates are visible and opt-in. The code running on your machine is the code you chose to install, not whatever a remote server decided to serve you today.

No File Semantics

WebRTC data channels send raw bytes. There's no concept of files, filenames, directories, metadata, permissions, or timestamps built into the protocol. Every file sharing app built on WebRTC has to implement all of this from scratch on top of raw data channels.

This means each app has its own custom protocol layered on WebRTC, with its own bugs, its own limitations, and its own approach to things like integrity checking, progress tracking, and error handling. There's no standard. What you get depends entirely on how much effort the developer put into solving problems that a purpose-built file transfer protocol handles at the protocol level.

What a Purpose-Built Approach Looks Like

A file transfer protocol designed from the ground up for moving files looks very different from WebRTC. The priorities are different: maximize throughput on the available connection, guarantee data integrity, handle interruptions gracefully, and support files of any size without memory constraints.

Handrive uses a native protocol built specifically for file transfer. It runs as a desktop application with direct access to the file system—no browser memory limits, no tab that needs to stay open. Transfers happen in the background. If a connection drops, transfer resumes where it left off. The protocol's congestion control is tuned for bulk data, not real-time media, so it actually uses the bandwidth available.

NAT traversal is handled at the application level with techniques optimized for sustained connections, not the ICE/TURN model designed for short-lived media sessions. And because it's a native app, the code on your machine is the code you installed—it doesn't re-download from a server every time you use it.

When WebRTC File Sharing Makes Sense

Browser-based WebRTC tools aren't useless. They have a real advantage: zero install. If you need to send a small file to someone once and don't want them to install anything, opening a browser tab and sharing a link is genuinely convenient.

For files under a few hundred megabytes, on a good network, between two peers that can connect directly, WebRTC file sharing works fine. The limitations don't matter much at that scale.

Where it breaks down is everything beyond that: large files, unreliable networks, NAT-heavy environments, repeated transfers, automation, and any situation where you need the transfer to be reliable rather than convenient. That's where using the right tool for the job—a protocol actually designed for file transfer—makes a real difference.