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. Our server handles discovery and the connection handshake, but not the file payload.
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:
This deployment's signalling server does not receive file data. File bytes are written to a WebRTC data channel that the server is not a party to, and the optional WebSocket file-transfer fallback in the underlying project is disabled here.
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. Trying both devices on the same ordinary Wi-Fi network or personal hotspot is the best first test, but it is not a guarantee: guest isolation, VPNs, firewalls, and managed-network rules can still block a peer connection.
Discovery and transfer connectivity are separate stages. If a device never appears, first check that both pages are open and online, then check whether a guest network, VPN, or proxy is separating them. Pairing or a public room can solve discovery across different networks, but neither creates a file relay.
If a device appears but the transfer never connects, signalling succeeded and WebRTC did not find a usable route. Changing to a common Wi-Fi network, a personal hotspot, or another network may help. Because this instance has no TURN or WebSocket file-transfer fallback, a transfer fails when no direct route can be established. Interrupted transfers have no durable checkpoint and must be started again. The FAQ has a step-by-step troubleshooting checklist.
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. Practical usage and download questions are covered in the FAQ.