How to Share Large Files Browser-to-Browser Without Upload Servers

You need to send a 4 GB video file to a designer on the other side of the office. What do you do? If you're like most people, you fire up WeTransfer, Dropbox, or Google Drive. You wait for the upload. They wait for the download. The file sits on someone else's server for 7 days, then it's gone. And if your file is over 2 GB, some of those services just say no.

There's a better way: send the file directly from your browser to theirs, with zero bytes touching a server.

How WebRTC File Transfers Actually Work

WebRTC (Web Real-Time Communication) is the same technology that powers video calls in Zoom, Google Meet, and Discord. But it also handles arbitrary data - including large files - through its RTCDataChannel API. Here's the flow:

• Signaling. Your browser creates an "offer" containing your connection capabilities (codecs, network details). This offer is sent to the recipient through a lightweight signaling server - typically just a WebSocket or a simple HTTP relay. The signaling server never sees the file data; it only exchanges connection metadata.
• ICE negotiation. Both browsers exchange ICE (Interactive Connectivity Establishment) candidates. These are potential routes for the direct connection: same-network LAN, public IP via STUN, or relayed via TURN if both peers are behind strict NATs.
• Direct peer connection. Once a route is found, the browsers connect directly. From this point forward, data flows peer-to-peer. The signaling server's job is done.
• Data channel transfer. The file is chunked into small pieces (typically 16 KB each, respecting the SCTP MTU), transferred over the encrypted data channel, and reassembled on the receiving end. Progress is tracked in real time.

The entire transfer uses DTLS encryption - the same encryption layer that secures HTTPS. Nobody on the network can read the data in transit, and the signaling server never touches the payload.

Why No-Upload Is More Private

When you upload a file to WeTransfer or Dropbox, you're trusting that company with your data. Even with "encryption at rest," the company holds the keys. Their terms of service typically grant them broad rights to scan, analyze, or share your content for abuse prevention, legal compliance, or even product improvement.

With a direct browser-to-browser transfer:

• The file never exists on any server (except the signaling metadata, which is discarded seconds after the connection is established)
• The transfer is end-to-end encrypted by WebRTC's DTLS - no middleman can decrypt it
• No account or login is required on either side
• No copy lingers on a cloud provider's storage after the transfer completes

For sensitive assets - design mockups for an unreleased product, legal documents, internal financial reports - this is a meaningful privacy improvement over "upload to cloud and share a link."

When P2P File Sharing Works Best

Direct transfers shine in specific scenarios:

• Same local network. Two people in the same office building can transfer files at LAN speeds (500 Mbps to 1 Gbps) instead of being bottlenecked by the building's internet uplink. A 5 GB file that takes 15 minutes over WeTransfer might take 30 seconds over the LAN.
• Same-office asset handoff. Designers sending PSDs to developers, video editors passing RAW footage to colorists, engineers sharing log dumps - any scenario where both parties are online and need the file now.
• Internal team tools. Instead of maintaining an internal file-drop server, teams can use a P2P transfer page that requires zero infrastructure. No S3 buckets, no file servers, no expiring-link cleanup scripts.

Practical Size Limits

The real limit isn't your internet connection - it's your browser's memory. WebRTC data channels stream data in chunks, and the receiving browser needs to reassemble the file in memory. Chrome and Firefox can typically handle files up to 2 GB before memory pressure becomes noticeable. For larger files, look for a tool that uses the File System Access API to stream chunks directly to disk.

Network speed matters too. A 10 GB file over a symmetric gigabit connection takes about 80 seconds. Over a typical residential uplink (20 Mbps), that same file takes nearly 70 minutes - and both browsers need to stay open the whole time.

When NOT to Use P2P File Sharing

Direct transfers aren't the answer for everything. Skip them when:

• Asynchronous transfers. The recipient needs to download the file tomorrow, but you want to send it now. P2P requires both parties to be online simultaneously. If the recipient closes their browser, the transfer fails. For async, you still need a server.
• Mobile browsers. Mobile Safari and Chrome aggressively throttle background tabs and WebRTC data channels. A transfer that works fine on desktop may fail or stall on a phone, especially for files over 100 MB.
• Strict corporate networks. Some enterprise firewalls block the UDP ports that WebRTC uses for ICE negotiation. The connection may fall back to a TURN relay, which re-introduces a server hop (and potential bandwidth limits).
• Large groups. Sending a file to 50 people? P2P means 50 separate upload streams from your browser. A traditional upload-to-server-and-share model is far more efficient here.

The Bottom Line

Browser-to-browser file sharing isn't a replacement for cloud storage - it's a complement. For the specific case where both parties are online, the file is too large for WeTransfer's cap, or privacy matters more than convenience, P2P transfer is faster, more private, and simpler to set up than any server-based alternative.

I build lightweight browser-based tools at utilitylab.dev. If you want a free, no-login tool to share files directly browser-to-browser without uploading to a server, there's one at https://utilitylab.dev/p2p-file-share.