What is the maximum file size limit on Share2Me?

There are absolutely no file size limits on Share2Me. Because the transfer is established directly peer-to-peer (P2P) between the sender and receiver browsers via WebRTC, the data does not pass through or store on any intermediate cloud server.

Is my data secure when transferring files and text?

Yes, completely secure. All transfers are end-to-end encrypted using military-grade AES-GCM-256 encryption. The encryption key is derived locally on your device via ephemeral ECDH (P-256) key exchange, meaning the raw key never leaves your browser and cannot be read by anyone, including the signaling server.

Do both devices need to be online at the same time?

Yes. Because Share2Me uses direct WebRTC peer-to-peer tunnels to transfer data, both the sending device and the receiving device must have the page open and be online concurrently to perform the transfer.

Can I transfer files between different operating systems?

Absolutely. Share2Me is entirely browser-native and cross-platform. It works seamlessly between iOS, Android, macOS, Windows, Linux, and any other operating system running a modern web browser, without needing any software installations.

Can I send clipboard text and messages securely?

Yes. Share2Me offers a dedicated Text Transfer mode. Copy-paste any text, passwords, or code snippets, and it will be encrypted and streamed securely through the same WebRTC pipeline, complete with a convenient 'Copy All' button for the receiver.

Tech Deep Dive

Under the Hood: How WebRTC Coordinates Direct P2P Connections

July 5, 2026

WebRTC (Web Real-Time Communication) has revolutionized the web by enabling direct peer-to-peer connections between browsers without plugin installations. While commonly associated with audio/video calls, its DataChannel component is a powerful tool for secure, serverless file transfer. In this technical deep dive, we explore how WebRTC negotiates connections, navigates network address translation (NAT) firewalls, and transfers binary data blocks securely.

1. The Signaling Phase: Exchanging the Handshake

WebRTC cannot establish a connection without an initial metadata exchange. This phase is called signaling. During signaling, peers exchange Session Description Protocol (SDP) packets, which contain information about media formats, cryptographic codecs, and network routing configurations. Although the connection itself is peer-to-peer, signaling requires an intermediate server—typically a WebSocket node—to relay these handshake offers and answers.

SDP Offer: The initiating browser describes its local connection capability.
SDP Answer: The receiving browser responds with its supported features.
Signaling Broker: A lightweight server (like Share2Me's Node engine) that handles the initial exchange and then steps out.

2. Navigating NATs and Firewalls: STUN, TURN, and ICE

Most consumer devices sit behind routers utilizing Network Address Translation (NAT), which shields their private IP addresses (like 192.168.1.5) from the public internet. To connect directly, a browser must discover its public-facing IP and port. This is coordinate by the ICE (Interactive Connectivity Establishment) protocol using STUN and TURN helper servers:

STUN (Session Traversal Utilities for NAT): A STUN server simply reflects back the browser's public IP and port, allowing the peer to establish a direct binding.
Symmetric NAT: Some strict routers block direct traffic from unknown IPs. In this scenario, STUN fails.
TURN (Traversal Using Relays around NAT): If direct connection fails, a TURN server relays the traffic. Although it acts as a relay, data remains end-to-end encrypted (AES-256) inside the browser, meaning the TURN operator cannot read your files.

3. RTCDataChannel and Binary File Streaming

Once a peer connection is established, the browsers instantiate an RTCDataChannel. DataChannels can be configured as 'reliable' (which guarantees packet delivery and order using SCTP over DTLS) or 'unreliable' (faster, like UDP). For file sharing, reliable SCTP is used. The browser reads files locally using the File System Access API, segments the data into binary chunks (typically 64KB), and streams them across the data pipe to the receiver, where they are assembled in memory and saved to disk.

Conclusion

WebRTC bridges the gap between client browsers, enabling high-performance, serverless data pipelines. Understanding these protocols explains how Share2Me (Share 2 Me) offers fast, private, and unlimited file sharing directly in your browser.