OpenDrop Setup Guide for Windows: Download to First Transfer

Before You Install: What OpenDrop Actually Does

OpenDrop is a file transfer application that moves files directly between devices without uploading them to any cloud server. I built it because I was tired of emailing files to myself just to get them from my iPhone to my Windows PC. The desktop version runs a local HTTP server on port 8000, advertises itself via mDNS so other devices can find it, and accepts file uploads from any OpenDrop client on the network.

On Windows specifically, the app includes both a graphical interface (the main window with drag-and-drop) and a command-line interface for scripting and automation. Both connect to the same underlying server. This guide covers the GUI path since that's what most people want, but I'll note where the CLI differs.

One thing worth understanding upfront: OpenDrop does NOT require both devices to be on the same WiFi network. Same network is faster because traffic stays local, but the app also supports remote transfers through Cloudflare tunnels (free) and a Fly.io relay (Pro). I'll explain both modes and when each kicks in.

Download Options: Microsoft Store vs Direct Install

There are two ways to get OpenDrop on Windows. The choice matters more than you'd think.

Microsoft Store: Search "OpenDrop" in the Store app or visit the store link from www.nfdgames.com/OpenDrop. The Store version auto-updates, runs in a sandboxed environment (MSIX packaging), and installs without needing admin privileges. The downside: Microsoft Store apps run in a slightly restricted sandbox that occasionally interferes with firewall rule creation. If Windows Firewall prompts don't appear on first launch, you may need to manually add a rule (I'll cover that below).

Direct download: The .exe installer from the website gives you a traditional Windows application. It installs to %LOCALAPPDATA%\Programs\OpenDrop\ and has full access to create its own firewall rules during installation. This version also includes the CLI binary alongside the GUI. I use the direct download on my Windows 11 desktop (Intel i7-13700K, 48GB DDR5) because the CLI is important for my workflow.

Both versions are identical in features. The Store version is simpler to install and maintain. The direct version gives you more control and includes the CLI out of the box.

Installation Internals: What Gets Put Where

After installation, OpenDrop creates a data directory at %LOCALAPPDATA%\OpenDrop\. This is NOT the same as your user profile's Downloads folder. Inside that directory:

• Files\ is the default storage directory where received files land
• settings.json stores your preferences (theme, storage path, server name)
• token.json stores authentication data if you sign in (stored as plain JSON, same approach Google's own client libraries use)

The application itself is compiled with Nuitka, a Python-to-C compiler. When compiled in windowed mode (no terminal window), Python's sys.stdout is None, so the very first lines of code redirect stdout and stderr to prevent crashes from stray print statements. This is a detail most users never see, but it explains why there's no console output even if you launch from a terminal.

The GUI is built on PySide6 (Qt for Python). If you've used other Qt applications on Windows, you'll recognize the rendering style, though we apply a custom dark theme with our own color palette. The application uses roughly 80-120MB of RAM at idle, which is comparable to other Python GUI applications.

First Launch: mDNS, Firewall, and Device Discovery

When you first launch OpenDrop, three things happen in rapid sequence.

The HTTP server starts on port 8000. This is the local server that handles incoming file transfers. It binds to 0.0.0.0 (all network interfaces) so it's reachable from any device on your network. The port number is fixed at 8000 and currently isn't configurable, though that rarely causes conflicts since most applications avoid that port.

mDNS advertisement begins. The app registers itself as _opendrop._tcp.local. on port 8000 using the zeroconf library. This is the same mDNS/Bonjour protocol that Apple uses for AirDrop and printer discovery. Every other OpenDrop instance on the network listens for this service type and adds new devices to its dashboard. Discovery typically takes 2-5 seconds depending on your network.

Windows Firewall may prompt you. On first launch, Windows should ask whether to allow OpenDrop through the firewall. Click "Allow access" for both private and public networks. If this prompt doesn't appear (common with the Microsoft Store version), you'll need to add the rule manually: open Windows Security → Firewall → Allow an app through firewall → Add OpenDrop. Without this rule, other devices can't reach your server, and you'll see them on your dashboard but they won't be able to send files to you.

After these three steps complete, your Windows machine appears on any other OpenDrop device on the same network. The dashboard shows connected devices with their names, IP addresses, and connection status.

Your First Transfer: Sending and Receiving Files

With OpenDrop running on your Windows machine and at least one other device (phone, Mac, Linux machine), you're ready to transfer files.

To receive files: Nothing to do. Just keep OpenDrop running. When someone sends a file from another device, it appears in %LOCALAPPDATA%\OpenDrop\Files\ by default. A notification pops up showing the filename and size. You can change the storage directory in Settings if you prefer a different location.

To send files from Windows: Click the upload button in the OpenDrop window or drag files directly onto the app. Select the target device from your connected devices list, and the transfer starts immediately. On the same network, files stream directly over HTTP without any size cap (up to 10GB). You'll see a progress bar with the current transfer speed.

To send files to Windows from a phone: Open the OpenDrop mobile app (available on iOS App Store and Google Play). Your Windows PC should appear in the device list within a few seconds. Tap it, select files, and send. The mobile apps are Flutter-based and handle the mDNS discovery, file selection, and upload progress natively on each platform.

If both devices aren't on the same network, the transfer still works but takes a different path. I'll explain how in the next section.

Under the Hood: How the Transfer Actually Happens

The transfer mechanism changes based on whether the devices are on the same network or not, and whether the user has a Pro subscription.

LAN transfer (same network, all users): The sending device makes a direct HTTP POST to the receiving device's IP on port 8000. The file streams as a single request body with no chunking, no intermediate servers, and no size limits (up to 10GB). This is the fastest mode. Every request is authenticated with HMAC-SHA256 signing: the client computes a signature over the HTTP method, path, timestamp, and body hash using a shared secret. The server verifies this signature and rejects requests with timestamps older than 30 seconds, which prevents replay attacks. On LAN, traffic is plain HTTP (not HTTPS) because the data never leaves your local network.

Remote free transfer (different networks): When devices aren't on the same network, OpenDrop establishes a Cloudflare tunnel via trycloudflare.com. This gives the server a public URL without port forwarding. The catch: Cloudflare caps request bodies at 5MB. So the sending device splits the file into 5MB chunks, uploads each one sequentially, and the receiver reassembles them. Throughput is around 8 Mbps. There's no file size cap in the sense that you can send any size file, but large files take proportionally longer. All traffic goes through Cloudflare's network, which provides TLS encryption in transit.

Remote Pro transfer (different networks, Pro users): Pro users bypass the Cloudflare tunnel entirely. Instead, the transfer goes through a Fly.io relay using WebSocket connections with binary frames. We switched from base64-encoded JSON payloads to raw binary frames after discovering that base64 encoding added 33% overhead. The relay supports true streaming up to 10GB at 30-50+ Mbps, which is 4-6x faster than the free chunked mode. The Fly.io relay also provides TLS encryption.

The connection priority is automatic: if both devices are on the same LAN, the transfer takes the direct local path. If not, it falls back to the remote path (relay for Pro, tunnel for free). You don't choose between these modes manually; the app handles the negotiation based on what it discovers during the mDNS phase and the Cloudflare/Fly.io connection state.

QR code pairing is available for situations where mDNS is blocked (hotels, corporate WiFi, some mesh networks). The QR code encodes the server's IP and port directly, bypassing the mDNS discovery step entirely. Scan it with the mobile app's camera and the connection establishes manually.

That covers the full path from download to your first transfer. The system is designed to be invisible once running: install, launch, and files move between your devices without thinking about protocols, ports, or network configuration. The complexity exists under the hood so you don't have to deal with it at the surface.