How ShareMeWeb Works
A plain-English explanation of the technology that makes instant, private file transfers possible — and the technical details for the curious.
The Short Version
When you share a file with ShareMeWeb, it travels directly from your browser to the recipient's browser. Our servers are only used for less than a second at the very beginning — to help the two browsers "find" each other on the internet. After that, they communicate directly and we're out of the picture entirely.
Your files never touch our servers. We technically cannot see what you're transferring.
Step-by-Step Walkthrough
Sender selects a file
You drag a file into the browser or click to browse. The file stays in your device's memory — it is not uploaded anywhere at this stage. ShareMeWeb reads its name and size to display information, but the bytes don't move yet.
WebRTC Offer is created
Your browser generates a WebRTC "offer" — a special document called an SDP (Session Description Protocol). It contains information about your network capabilities, supported codecs, and how to reach you. Think of it like handing someone your business card so they can call you back.
Signaling server creates a session
The offer is sent to ShareMeWeb's lightweight signaling server, which assigns it a unique session ID and stores it temporarily in memory (never on disk). A QR code and link are generated containing this session ID. The signaling server's only job is to relay these small handshake messages — it never sees your file data.
Receiver scans the QR code
Using their phone camera or by pasting the link into any browser, the receiver opens the session. Their browser fetches the sender's SDP offer from the signaling server and generates an "answer" SDP in return. Both browsers now know how to reach each other.
ICE candidate exchange
Behind the scenes, both browsers gather "ICE candidates" — essentially a list of possible ways to connect (local IP, public IP via STUN server, relay via TURN server). These candidates are exchanged through the signaling server until a working path is found between the two browsers. This typically takes 1–3 seconds.
P2P DataChannel opens
Once both sides agree on a connection path, WebRTC establishes a RTCDataChannel — a direct, reliable, ordered binary channel between the two browsers. DTLS encryption is applied automatically by the WebRTC standard; there is no option to turn it off.
File is chunked and streamed
The sender's browser reads the file in 64 KB chunks using the FileReader API and sends each chunk through the DataChannel. The receiver's browser collects these chunks and reassembles them in order. Progress bars on both sides update in real time. When the last chunk arrives, the receiver gets a download prompt automatically.
Session expires automatically
Once the transfer is complete (or after 30 minutes of inactivity), the session ID is deleted from the signaling server's memory. The WebRTC connection closes. No trace remains on our infrastructure.
Technology Stack
WebRTC
Browser-native P2P protocol with built-in DTLS encryption
Socket.io
Lightweight signaling — only used during handshake (~1KB of data)
QR Code
Session URL encoded as QR for easy mobile scanning
Node.js
Tiny signaling server — handles no file data whatsoever
Frequently Asked Questions
Is there a file size limit?
There is no server-imposed size limit because files never touch our servers. The practical limit depends on your device's available RAM — transferring multi-gigabyte files requires enough memory to buffer the data. For most files (documents, photos, short videos), there are no issues.
Does it work across different networks?
Yes. When both devices are on the same WiFi network, the transfer goes through your local router and is extremely fast. When devices are on different networks, WebRTC automatically finds a public route using STUN servers. In rare cases (corporate firewalls, strict NAT), a TURN relay server may be used — though the relay only sees encrypted data.
What browsers are supported?
All modern browsers support WebRTC DataChannels: Chrome 56+, Firefox 44+, Safari 15+, Edge 79+, and all modern mobile browsers. Internet Explorer is not supported.
Is the transfer encrypted?
Yes. WebRTC mandates DTLS (Datagram Transport Layer Security) encryption on all DataChannel connections. This is enforced at the browser level — it cannot be disabled. The encryption keys are negotiated directly between your browsers and are never shared with our servers.
What happens if the connection drops?
The current transfer will stop. You'll need to start a new session. We're working on resumable transfers for a future release.
Can I send to multiple people simultaneously?
Currently, each session supports one sender and one receiver. For sharing with multiple people, generate a new session for each recipient.