1. The Mechanics of WebRTC DataChannels

WebRTC (Web Real-Time Communication) is an open-source standard embedded directly into modern browsers. While most people associate it with video conferencing applications like Google Meet, its RTCDataChannel API is one of its most powerful and underutilized features. RTCDataChannel allows the transport of arbitrary binary or text data directly between two browser instances, without the data ever touching a server. This is a fundamentally different model from HTTP uploads, where every byte must travel to a server before reaching the recipient. The DataChannel API supports two reliability modes: reliable mode (using SCTP over DTLS), which guarantees packet delivery and ordering similar to TCP, and unreliable mode which prioritises speed over reliability, similar to UDP. For file transfers, reliable SCTP is always used because losing a single byte of a binary file corrupts it entirely. The practical result is that a 10 GB file transferred over a WebRTC DataChannel never touches any cloud storage, accumulates no server hosting costs, and is subject to no artificial file size caps. The transfer speed is limited only by the physical network connection between the two devices, whether that is a 100 Mbps home Wi-Fi connection or a 1 Gbps fiber link.

• Direct Connection: Data flows directly between peers, utilizing the full local network speed without server bandwidth caps.
• Low CPU Overhead: Browsers stream binary data using native low-level socket connections, reducing CPU load compared to JavaScript-based libraries.
• Zero Server Storage: Servers are completely bypassed during data transfer, eliminating hosting security risks and compliance concerns.
• No File Size Limits: Without a server to constrain storage, transfers are limited only by available network bandwidth and RAM.

2. The Role of Signaling, STUN, and TURN Servers

If WebRTC is peer-to-peer, you might wonder how two browsers find each other on the internet. The answer is a process called signaling. Before a direct connection is established, the two browsers must exchange Session Description Protocol (SDP) packets — structured metadata that describes each browser's network configuration, supported codecs, and cryptographic capabilities. A signaling server acts as a temporary message relay for this initial handshake. Share2Me uses a lightweight Node.js WebSocket server for signaling. Once the handshake is complete, the signaling server steps back entirely and the browsers communicate directly. The complication is that most devices sit behind routers that use Network Address Translation (NAT) — a technology that maps private IP addresses (like 192.168.1.5) to a shared public IP. NAT hides the device's true network address, making it difficult for an external browser to reach it directly. To solve this, WebRTC uses two additional helpers: STUN servers, which are simple public utilities that reflect back your browser's externally-visible IP address and port, and TURN servers, which act as fallback relays when symmetric NATs block all direct paths. Even when traffic is routed through a TURN relay, it remains fully end-to-end encrypted inside the browser — the TURN operator cannot read the data.

• Signaling Server: A WebSocket server (Share2Me's Node.js engine) used only to exchange the initial SDP offer/answer — it never sees your files.
• STUN Servers: Public utilities (like Google's stun.l.google.com) that discover your external IP and port configuration.
• TURN Servers: Encrypted fallback relays used when symmetric NAT firewalls block direct connections — data remains unreadable by the relay.
• ICE Framework: Interactive Connectivity Establishment — the protocol that orchestrates STUN/TURN lookups and selects the optimal connection path.

3. Bypassing File Size Limitations and Throttling

Traditional cloud storage platforms restrict file sizes to control their hosting infrastructure costs. Google Drive limits uploads to 5 TB per file for paid users and 750 GB total per day. WeTransfer caps free transfers at 2 GB. Email attachments are limited to 25 MB. All of these limits exist because the cloud platform is paying for the bandwidth and disk space to host your file. WebRTC completely eliminates this calculus. Because a direct RTCDataChannel sends data point-to-point without an intermediate server, there are no artificial restrictions. The browser reads files using the File System Access API or FileReader, splits the data into binary chunks (typically 64 KB to 256 KB per chunk), encrypts each chunk locally using AES-GCM-256, and streams the chunks sequentially across the data channel. The receiver's browser assembles the chunks in memory and writes the final file to disk once the transfer completes. Memory usage on both sides is minimal — the browser only holds a small window of chunks in memory at any one time rather than loading the entire file.

4. How to Make a P2P Transfer with Share2Me

Making a direct browser-to-peer transfer with Share2Me takes under 30 seconds. On the sending device, open share2.me and click 'Start P2P Tunnel'. Select the files you want to share. The browser generates a 6-digit One-Time Code and a QR code. The receiver opens share2.me on their device and enters the code (or scans the QR code). Once matched, the browser performs the ECDH key exchange and establishes the WebRTC DataChannel. The file transfer begins immediately. Both devices must remain online and have the browser tab open for the duration of the transfer. There are no accounts, registrations, or app downloads required on either device.

• Step 1: Open share2.me on the sending device, click 'Start P2P Tunnel', select files.
• Step 2: Share the 6-digit code or QR code with the receiver verbally, by text, or by showing the screen.
• Step 3: The receiver opens share2.me and enters the code — the connection and transfer begin instantly.
• Step 4: Once the transfer bar reaches 100%, the receiver's browser prompts to save the file to disk.