copyparty vs Syncthing

Last reviewed Aug 26, 2026 · 750 words

Syncthing has no web file browser and copyparty has no sync client; that pair of absences settles almost every version of this question. One keeps a folder mirrored across your laptop, desktop and phone with nothing in the middle. The other turns a folder on one machine into a web page you can browse, upload to, mount and share from. Both sit under file sync because both replace Dropbox, but they replace different halves of it.

The sync engine that refuses to serve

Syncthing (MPL-2.0, Go, 87,991 stars, 128 MB) connects devices by ID, shares folders between them, and keeps them identical over TLS with no central server, no account, and no cloud in the path. Conflicts become .sync-conflict files rather than silent overwrites, versioning can keep old copies, and untrusted-device encryption lets a VPS hold a copy it cannot read. The GUI on port 8384 administers devices and folders; it does not open files, and there is no share link and no upload page. The catalogue's gotcha is the one that matters: sync traffic uses port 22000 and discovery 21027, so the 8384 GUI should never face the internet. Run it on localhost or over Tailscale and forget it exists.

One cost surfaces late: every device with the folder stores the whole folder, so a 400 GB archive needs 400 GB on each participant unless you split it into subfolders by hand. Syncthing is a mirror, not a remote drive.

The server that lives in one file

copyparty (MIT, Python, 46,394 stars, 64 MB) is a single copyparty-sfx.py you run with python3 and a handful of flags, or a Docker image if you prefer. Point it at a directory and you get a browsable web UI on port 3923, uploads that survive a dropped connection, deduplication, an audio player, thumbnails, and a search index if you turn one on. The same volume is reachable over WebDAV for mounting in Finder or Explorer, FTP for the old scanner, and TFTP for network boot. Accounts and per-volume permissions live in flags too: -a alice:hunter2 -v /srv/share:share:r:rw,alice says everyone reads, alice writes.

The catalogue cons are accurate. The interface is dense and looks like nothing else, and there are hundreds of flags. What copyparty cannot do is keep two machines in step; it is one authoritative copy that clients visit.

Resumable uploads are the feature that decides edge cases

A 40 GB drive image over flaky hotel wifi is where copyparty's up2k protocol earns its "accelerated resumable uploads" tagline: chunks are hashed, uploaded in parallel, and a browser refresh three hours in picks up where it left off. Syncthing moves the same file block by block and resumes after interruptions on its own, but only to devices already paired. A friend without Syncthing means copyparty by default; your own NAS means Syncthing, with no browser and no clicking.

Running both on one directory

The pattern I use: Syncthing mirrors ~/sync between laptop, desktop and a server; copyparty on the server exposes that same ~/sync read-only to the web and a separate ~/inbox writable for uploads, which Syncthing then pulls back to the desktop. Each tool does the thing the other refuses to. The catch is write contention: give copyparty write access only to directories Syncthing treats as receive-only on other devices, or you will manufacture conflict files. The heavier all-in-one alternative is the subject of Nextcloud vs Syncthing.

Decision table

What I'd do

Syncthing first, on every device you own, because keeping your own files current is the daily problem and it does that with no attention. Add copyparty the day you need a link, a WebDAV mount or an upload page, point it at the synced directory, and lock its writable volumes to a dedicated inbox. Neither is a backup; both will faithfully replicate a deletion, so keep the 3-2-1 discipline running underneath whichever you choose.