Snapdrop

Last reviewed Aug 26, 2026 · 736 words

Snapdrop works, and I would still deploy PairDrop instead. Same idea (open a page on 2 devices, they see each other, drag a file across), same WebRTC plumbing, same one-container footprint, but PairDrop is an actively maintained fork that adds pairing across networks, while the original Snapdrop repository has seen little development for some time. Everything below applies to both, because PairDrop is Snapdrop with the rough edges filed off, and the operational trap in the second section is the thing that catches most people on either.

How "same network" actually works

There is no discovery protocol. The server is a small Node.js signalling service; every browser that loads the page opens a WebSocket to it, and the server puts peers into the same room when they arrive from the same public IP address. On a home network everyone shares one NAT address, so everyone sees everyone. That is the entire mechanism, and it has two consequences. Devices on a guest Wi-Fi with a separate WAN address will not see the main network. And when the phone is on mobile data it sees nobody, which is the "same network only" limitation in the catalogue and the reason PairDrop added explicit pairing codes.

The reverse proxy header that breaks everything

Self-hosted behind Caddy, nginx or Traefik, the signalling server sees every connection arriving from the proxy's own address. Without the real client IP, every user in the world lands in one room, or on a stricter setup nobody appears at all. The fix is passing X-Forwarded-For through, which Caddy does by default for reverse_proxy, and which nginx needs set explicitly:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

The WebSocket upgrade headers are the other half; forget them and the page loads but no devices ever appear. Most "my Snapdrop shows nothing" reports come down to one of these lines.

HTTPS is not negotiable, and the transfer never touches the server

The page is a progressive web app, and browsers require a secure context for the service worker, for clipboard sharing and, in practice, for the WebRTC session to negotiate reliably. So the deployment is always container plus TLS proxy. Once two peers find each other the file moves over a direct WebRTC data channel between the devices; the server only made the introduction and never sees the bytes. That is why a 64 MB container can serve a whole office, and why a 4 GB video over Wi-Fi is limited by your access point, not your server. The linuxserver/snapdrop image is the usual packaging, and the whole thing is a docker run plus a Caddy site block.

Against LocalSend: browser versus app

LocalSend is the other self-hosted answer to AirDrop, and the split is clean. LocalSend needs an app installed on each device but needs no server, discovers peers over multicast, and works on a network with no internet at all. Snapdrop and PairDrop need nothing installed (a visitor with a phone and a URL is in) but need a server and an HTTPS certificate. For a household that owns all its devices, LocalSend is less to run. For handing a file to a guest, a locked-down work laptop, or a smart TV browser, the web version is the one that works.

Should you run the original at all

Only if you already have it running and it does the job. For a new deployment there is no advantage to the older codebase, the security surface is identical, and PairDrop's pairing and public-room features are pure additions. The file-sync category covers the heavier tools for the case where you want files to arrive without anyone dragging them; Snapdrop-style transfer is for the moment when you want a photo on the other screen right now.

What I'd do

PairDrop in a container behind Caddy on a hostname every device can reach, X-Forwarded-For verified on day one by opening it on two devices, and LocalSend installed on the family's own phones and laptops as the everyday tool. Keep the web version for guests and for anything that cannot install an app. Give the original Snapdrop credit for the idea, and let the fork run it.