Most "send a file" services work by uploading your file to a server, giving you a link, and letting the other person download it. SnapDrop does not do that. Your file goes directly from one device to the other, and the only thing our server ever handles is the introduction.
This page explains what that actually means, because "peer-to-peer" is a claim worth being specific about.
Transfers run over WebRTC, a browser feature designed for direct connections between two machines. Once the connection is established, your browser opens a data channel to the other browser and writes the file into it in 64 KB chunks.
WebRTC data channels are encrypted with DTLS. This is not optional and not something we implemented — the browser will not open an unencrypted data channel. So the file is encrypted by your browser before it leaves the device, and decrypted by the receiving browser.
Two browsers cannot find each other unaided. Something has to pass the first messages between them, and that is the only job our server has. It is called a signalling server, and it handles three things:
The signalling server never receives file data. It is not a design goal that we enforce carefully — it is structural. File bytes are written to a WebRTC data channel that the server is not a party to, and there is no code path that sends them anywhere else.
Devices are usually behind a router doing network address translation, so neither knows the address the other should dial. WebRTC solves this with a STUN server: your browser asks it "what address do I appear to come from?", and the answer becomes one of the candidates offered during the handshake. This instance uses Google's public STUN server for that. A STUN request reveals your IP address to that server; it carries no file data and no information about what you are sending.
On a home or office network this is usually enough. Some networks — symmetric NAT, certain corporate firewalls, some mobile carriers — will not permit a direct connection at all. The standard workaround is a TURN relay, which forwards the encrypted stream between the two devices.
This instance does not run a TURN server. If a direct connection cannot be established, the transfer fails rather than falling back to a relay. That is a deliberate trade-off: it means there is no configuration under which your file passes through infrastructure we operate, at the cost of not working on every network. If a transfer will not start, both devices being on the same Wi-Fi is the reliable fix.
Sharing a public IP address only helps when both devices are on the same network. Pairing is how you connect devices that are not.
One device requests a pairing key — six digits, also rendered as a QR code. Entering that key on a second device tells the server the two belong together, and the server hands both a shared secret. Each browser stores that secret locally. From then on, both devices join a room derived from the secret whenever they connect, so they find each other regardless of which network they are on.
The pairing key is single-use — it stops working the moment a second device redeems it, and it is also dropped if you cancel, request a new one, or close the tab. The secret it establishes is what persists. Unpairing deletes that secret from your device and from the server's routing table, and because it lives in your browser's storage, clearing site data unpairs everything.
A public room is the temporary version of pairing, for sending something to a person rather than to your own other device. One person creates a room and gets a short code; anyone who enters that code joins the same room and can see and send to the others in it.
Rooms are ephemeral. They exist in the server's memory while someone is in them and vanish when the last participant leaves — there is no record of who was in a room or what moved through it. Anyone with the code can join while it is active, so treat the code as the only access control there is.
What the server does record, and for how long, is set out in the privacy policy.