Technical content reviewed: 3 September 2026
This guide is for the public SnapDrop instance at snap-drop.net. It explains
what to do when two devices cannot see each other, why a visible device may still fail to
connect, what happens to received files, and which limits come from the browser rather than
from SnapDrop.
For the protocol and server architecture, read how SnapDrop works. For the data-handling contract, read the privacy policy.
You need two devices with this site open, JavaScript enabled, and an active network connection. Current mainstream versions of Chrome, Edge, Firefox, and Safari normally provide the WebSocket and WebRTC data-channel features SnapDrop uses. Older browsers and embedded in-app browsers may not. Installing the site as an app is optional; pairing, notifications, clipboard access, and mobile share-sheet integration also depend on what the browser and operating system allow.
Keep both pages open while sending. An offline copy of the app can open from its cache, but it cannot discover another device or transfer anything until it reconnects.
Open SnapDrop on both devices and wait for the other device's name to appear. Select that device, choose one or more files, and approve the request on the receiver. On a desktop you can also drag files onto a device. To send text or a link, right-click the device on a desktop, or touch and hold it on a phone or tablet, then use the message box.
Device names are convenient labels, not verified identities. Before sending something private, confirm with the other person that you selected the device they can see on their screen.
Not always. Devices that reach the site from the same apparent public IP address are placed in the same local discovery room automatically, which is why the same Wi-Fi often works with no setup. SnapDrop does not scan your local network. Guest Wi-Fi isolation, a VPN, a proxy, different IPv6 routes, or a managed network can therefore stop two nearby devices from appearing even when their Wi-Fi name looks identical.
For devices on different networks, pair devices you control or create a temporary public room. Those features help the devices discover each other; the file itself still needs a viable WebRTC route between the browsers.
Pairing is for devices you expect to use together again. One device creates a single-use six-digit key and QR code. Redeeming it gives both browsers a shared secret that is saved in their local site data and used for discovery on later visits. Clearing site data, using storage-restricted private browsing, or unpairing can remove that relationship. Two tabs in the same browser cannot be paired with each other.
A public room is better for a temporary transfer with another person. It uses a five-letter code, can contain several devices, and disappears from server memory after the last participant leaves. Anyone who has the active code can join, so share it only with the intended participants. Neither option makes a blocked WebRTC route work by itself.
No. The transfer runs in the web page and there is no account. A supported browser may offer to install SnapDrop as a progressive web app or expose it in the system share sheet, but those are conveniences rather than requirements. If an embedded browser inside another app behaves oddly, open the site in a full browser instead.
The file picker does not restrict file types, and you can select multiple files. SnapDrop does not implement folder selection, so make a ZIP or another archive first if you need to preserve a folder structure. Sending several files causes the receiver to prepare a ZIP in the browser in most desktop cases.
SnapDrop has no server upload limit because files are not uploaded to its server, but that does not make transfers unlimited. The receiving browser holds each completed file in memory before saving it, and preparing several files as a ZIP needs additional memory. Available memory, storage space, browser behavior, and device power therefore set the practical ceiling.
This client rejects an incoming batch on iPhone or iPad when its combined size is 200 MiB or more. Keep each iOS batch below that threshold, and use smaller batches on older or memory-constrained devices. There is no single safe maximum for every other browser.
Speed is determined by the path between the two browsers, the devices, and their network conditions—not by an upload tier on this site. A local Wi-Fi route can be much faster than a route across the Internet. Busy wireless networks, power-saving modes, VPNs, and slow storage can all reduce throughput. Files in a batch are sent one after another.
SnapDrop waits for the whole file to arrive, then asks the browser to download or share it. One file is normally saved under its original filename; several files are normally offered as an uncompressed ZIP. On supported Android and iOS browsers a Share button can pass the received files to the system share sheet. The exact download directory, permission prompt, and final save name are controlled by your browser and operating system.
If the transfer says it completed but no file appears, return to the receive dialog and choose Download or Download again. Also check whether the browser blocked automatic downloads and whether the device has enough free storage.
It preserves the file bytes and filename. It does not preserve every filesystem attribute: for example, the received browser file is created with the current time rather than the original modification time. The protocol checks the expected filename and byte count, but it does not provide a user-visible cryptographic checksum. Compare a checksum separately when exact archival verification matters.
No. The live data channel uses reliable delivery and acknowledgements, but SnapDrop does not save a durable checkpoint that another session can resume. Closing or reloading a page, losing the route, or allowing the operating system to discard a tab tears down the transfer. Reopen both pages and send the file again.
On a large shared network, a device you do not recognize can occasionally appear because several users share one public address. Do not send to it. The displayed name is not proof of who owns the device.
Discovery and file connectivity are separate. Seeing a device proves that both browsers reached the signalling service; it does not prove that WebRTC found a usable path between them. Corporate firewalls, restrictive address translation, VPN policies, carrier networks, and blocked peer-to-peer traffic can prevent that path.
Try putting both devices on the same ordinary Wi-Fi network or personal hotspot, or try a different network. This public deployment advertises a STUN server but no TURN relay and has no WebSocket file-transfer fallback. STUN helps browsers discover and test possible routes; it does not carry the file. If the browsers cannot establish a direct route, this instance fails the transfer rather than uploading or relaying it through the server.
A device may have slept, changed networks, lost Wi-Fi, run short of memory, or had its background page frozen or discarded. A brief connection disturbance is not guaranteed to be fatal at the WebRTC layer, but this client does not restart ICE or resume a file after it reports the peer disconnected. Keep both devices awake, leave both pages visible when practical, and retry with a smaller batch or a more stable network.
To avoid exhausting browser memory, this client refuses an incoming iOS batch whose total size is 200 MiB or more. Split the selection into batches below 200 MiB. A smaller batch can still fail if the device is short of memory or storage, so reduce it further when necessary.
Sometimes a transfer continues, but the web platform cannot guarantee it. Browsers and operating systems may throttle, freeze, or discard background pages, and a screen wake lock can be released. For the most reliable result, keep both pages in the foreground and both devices awake until the completion message appears.
No file bytes pass through this deployment's application server. With the current production configuration, the browsers exchange files over a direct WebRTC data channel; there is no TURN or WebSocket file relay and no file database. Both devices must be online together because the service does not create a later download link. The privacy policy describes the signalling and infrastructure data that is handled separately.
WebRTC data channels are encrypted in transit with DTLS by the browsers. Encryption protects the live transport, but it does not tell you who owns a device name. SnapDrop has no account-backed identity and no independent, out-of-band verification of the other browser. Confirm the recipient yourself, keep public room codes private, and enable automatic acceptance only for a paired device you trust.
The service necessarily handles connection metadata used to introduce browsers: the source IP address, browser-derived device information, a random peer identifier, room or pairing identifiers, and WebRTC session and network-candidate messages. Its signalling connection remains open for presence and handshakes while you use the page. In the current production configuration, filenames, thumbnails, message text, and file bytes stay on the peer data channel rather than being sent through the application server.
Share only material you own or are authorized to distribute, and only with a recipient who agreed to receive it. Do not use SnapDrop for unlawful material, malware, harassment, or copyright infringement. SnapDrop neither hosts nor indexes a public catalogue of files, and the operator cannot inspect peer-to-peer file contents; those architectural limits do not change your responsibility for what you send. Read the full terms of use before using the service.