PairDrop review: browser file transfers, self-hosted or on pairdrop.net

The problem PairDrop solves, and who actually needs it

Moving a file between a phone and a laptop on the same desk is still awkward. AirDrop covers Apple devices only. Email attachments recompress photos. Cloud drives round-trip the bytes through someone else's datacenter and often need an account. PairDrop targets exactly that gap: the README describes it as "Local file sharing in your web browser", inspired by Apple's AirDrop and forked from Snapdrop.

The audience is broader than the name suggests. The README lists three concrete situations: sending a file from a phone to a laptop, sharing photos in original quality between Android and iOS friends, and private peer-to-peer transfers between Linux systems. The repository also ships a pairdrop-cli directory and the README points to instructions for sending files from the Nautilus context menu on Ubuntu, from the Windows context menu, and from the iOS and Android share sheets. So there are two distinct users here: someone who opens pairdrop.net in a tab, and someone who wants the transfer path wired into their desktop shell.

One caveat up front. The README's feature list is written as a list of capabilities, not as a security document. If your reason for choosing PairDrop is that files never leave your network, that claim depends on how you deploy it, not on the project name.

How PairDrop moves bytes: WebSockets for signalling, WebRTC for the payload

The architecture is visible in the repository layout and the dependency list. The server is a Node.js process (server/index.js, started by npm start) with express, ws, express-rate-limit, ua-parser-js and unique-names-generator as its only runtime dependencies. The frontend is described as vanilla HTML5, JS ES6 and CSS 3, packaged as a progressive web app.

The split matters. WebSockets carry signalling: who is on the network, what their display name is, and the metadata needed to negotiate a connection. The file itself travels over a WebRTC peer-to-peer data channel. That is why the README can say devices on the same local network discover each other, and why hosting it yourself changes discovery: the README notes that when you host PairDrop yourself, all peers connected with private IPs are discoverable by each other.

For connections that cannot be established directly, the README states that devices outside the local network behind a NAT are auto-connected via the PairDrop TURN server. Self-hosters can override this: the README points to specifying your own STUN/TURN servers, and the repository carries rtc_config_example.json and turnserver_example.conf plus a docker-compose-coturn.yml. Persistent pairing works through a 6-digit code or QR code and shared secrets, while temporary public rooms use a 5-letter code. Those two mechanisms are separate: pairing survives a restart, rooms do not, and the README says closing PairDrop leaves all rooms. IndexedDB holds client-side state, which is what makes pairing persistent in the browser.

Installing PairDrop with Docker and sending your first file

The README points to docs/host-your-own.md for Docker or Node.js hosting. The repository's docker-compose.yml uses the LinuxServer image and binds the web UI to localhost on port 3000. The comments in that file are the clearest statement of the available switches.

services:
  pairdrop:
    image: "lscr.io/linuxserver/pairdrop:latest"
    container_name: pairdrop
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - WS_FALLBACK=false
      - RATE_LIMIT=false
      - RTC_CONFIG=false
      - DEBUG_MODE=false
      - TZ=Etc/UTC
    ports:
      - "127.0.0.1:3000:3000"

WS_FALLBACK controls whether traffic can fall back to the websocket path when a WebRTC connection is not available to the client. RATE_LIMIT, when true, limits clients to 1000 requests per 5 minutes. RTC_CONFIG takes the path to a file describing your STUN/TURN servers. Leave RTC_CONFIG as false and you get the default behaviour described in the README.

If you prefer to run it directly, package.json defines two scripts. npm start runs node server/index.js. The production variant adds flags:

npm run start:prod

That script is node server/index.js --rate-limit --auto-restart, so rate limiting and automatic restart on error are opt-in flags rather than defaults. Node 15 or newer is required by the engines field. The Dockerfile exposes 3000 and runs a healthcheck against http://localhost:3000 every 30 seconds.

Once the container is up, open the bound address in a modern browser on two devices on the same network. Each device appears under a generated display name, which you can change. Click the peer, pick files, and the transfer begins after the other side accepts. The README states files are auto-downloaded on completion where the browser allows it, and that multiple files arrive as a ZIP.

Where PairDrop is the wrong tool

The most important limitation is one the README does not address: it does not document a threat model, key verification, or what a malicious peer on the same network can observe. PairDrop's discovery model is deliberately open. On a self-hosted instance, every peer with a private IP is discoverable by every other peer, which is the point on a home LAN and a problem on a shared corporate or campus network. Public rooms are worse in that respect: all devices in the same room see each other, and a 5-letter code is a short secret.

The second limitation is the fallback path. WS_FALLBACK exists precisely because WebRTC sometimes cannot connect, and when it is enabled the traffic takes a different route than the peer-to-peer channel. If your reason for using PairDrop is that the payload never touches the server, enabling WS_FALLBACK weakens that property, and the compose file's comment does not spell out the consequence.

Third, this is a browser application. It needs a modern browser on both ends, and features like auto-download depend on what that browser permits. The README also lists heic2any for HEIC/HEIF conversion, which tells you iPhone photos are converted client-side rather than transferred untouched in every case.

Finally, the project is not archived, but the last push was on 2026-04-22 and the most recent release is v1.11.2 from 2025-02-24. That is not an abandoned repository, and it is not a fast-moving one either. Treat the release cadence as slow.

PairDrop compared with Snapdrop and ShareDrop

PairDrop is a fork of Snapdrop, and the README devotes a long section to the differences, so the comparison is not speculative. Snapdrop's model is local-network discovery and nothing else. PairDrop adds two mechanisms on top: persistent device pairing through a 6-digit code or QR code using shared secrets, and temporary public rooms entered with a 5-letter code. Those exist for a specific reason, stated in the README: connecting to devices in complex network environments such as public Wi-Fi, company networks, iCloud Private Relay, VPNs, and mobile hotspots.

The second difference is the transfer UX. PairDrop transfers after a request is accepted, auto-downloads where possible, bundles multiple files into a ZIP, and shows an overall progress indicator. Snapdrop's issue tracker is cited in the README as the origin of the improved send and receive interface, so this is a deliberate departure rather than an accident.

ShareDrop is the other name people search for in this space. It solves the same basic problem of browser-based peer transfer, but the repository here contains no detail about its architecture, so the only honest comparison is at the level of intent: PairDrop's distinguishing feature is the pairing and room layer plus a self-hosting story with documented STUN/TURN configuration. If you only ever transfer between two devices on one home network, Snapdrop's simpler model is a reasonable choice and PairDrop's extra machinery buys you little.

Licence, maintenance and what upgrading costs

The repository is GPL-3.0. The practical implication for a self-hoster is the usual copyleft one: if you distribute a modified PairDrop, the GPL's source-availability terms apply to your version. Running an unmodified instance on your own network is a different situation from shipping a modified build to customers, and the repository's licence file is the authority, not this paragraph. Note the mismatch worth knowing about: package.json declares "license": "ISC" while the repository carries a GPL-3.0 LICENSE file. That inconsistency is in the source, and anyone doing a formal licence review should raise it rather than assume either value.

On maintenance, the facts are narrow. The repository is not archived. The last push was on 2026-04-22. The newest release in the list is v1.11.2, published on 2025-02-24, following v1.11.1 on 2025-02-19 and v1.11.0 on 2025-02-17. The gap between the last release and the last push means changes are landing on master without a tagged release behind them, so pinning to a version tag gets you code older than the branch.

Upgrade cost is mostly configuration, not migration. There is no database and no documented schema to migrate; the compose file's environment variables (WS_FALLBACK, RATE_LIMIT, RTC_CONFIG, DEBUG_MODE, PUID, PGID, TZ) are the surface you manage. The docker-compose.yml references lscr.io/linuxserver/pairdrop:latest, a floating tag. If you run that as written, you are upgrading on every pull, which is convenient and also means the version you tested is not the version you get next week. Pin a digest or a version tag if that matters to you. The README does not document rollback procedures.

Editorial conclusion

Adopt PairDrop if you want a self-hosted transfer page on your own LAN and you are comfortable reading the host-your-own document before exposing it. Do not adopt it if you need audited end-to-end guarantees, a documented threat model, or a supported enterprise deployment. Verify first whether WS_FALLBACK and RTC_CONFIG are set the way your network needs them, and confirm the image tag you are pulling matches the version you intend to run.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. schlagmichdoch/PairDrop on GitHub