SyncClipboard: cross-platform clipboard sync with a history store you host

What SyncClipboard solves, and who ends up running it

Copying text on one machine and pasting it on another usually means a cloud clipboard tied to an account you do not control, or a manual paste into a chat window. SyncClipboard takes the third route: the clipboard content moves through a server that you or your team operates. The README lists three desktop platforms (Windows, macOS, Linux) and describes real-time clipboard sync plus clipboard history management and history sync. Mobile is handled through separate clients: iOS Shortcuts, several Android options including SyncClipboard Mobile from the same author, and ClipLink on HarmonyOS Next.

The audience is narrower than "anyone who copies text." You need somewhere to put the server, or an existing WebDAV drive, or an S3-compatible bucket. If you have none of those, the desktop client's built-in server is the fallback. That is the lowest-friction path, but it makes one desktop machine the hub for the others, which is a different reliability story from a container on a host that stays up.

The sync network: server, clients, and what travels between them

Every participant in a SyncClipboard setup speaks to a server. The server can be the standalone SyncClipboard.Server, the server embedded in the desktop client, a WebDAV endpoint, or S3-compatible object storage.

The desktop clients sync automatically while running in the background. The README also documents two command-line arguments: --shutdown-previous, and a family of --command-{command-name} flags. The server exposes an API with endpoints for getting the clipboard and uploading the clipboard, plus the SyncClipboard.json format and an S3 sync protocol specification. The version history matters here: v3.1.1 and later clients and servers are not compatible with earlier versions, and the README states that clients, servers and third-party clients in one sync network must be upgraded together.

Installing the server with Docker and pairing the first desktop client

The README's server section covers a standalone server, SyncClipboard.Server, with subsections for server configuration, Docker and Arch Linux, alongside the server built into the desktop client.

For the client, download the installer or archive from the releases page: names beginning with SyncClipboard_win_ for Windows, SyncClipboard_macos_ for macOS, SyncClipboard_linux_ for Linux. Windows 10 2004 is the minimum supported version. On macOS, Gatekeeper may block the app; the README's fix is to open Privacy & Security settings and click Open Anyway, and if macOS reports the app is damaged, run the quarantine removal command it prints. Some macOS features depend on Accessibility permission, which the app prompts for.

History is the feature to treat with suspicion

The README carries a warning above the fold: the clipboard history feature is at an early stage, and users should be prepared to lose all of that information, keeping important data somewhere other than this tool. That is unusually direct, and it should shape how you deploy SyncClipboard. Sync is the mature part; history is the part with an explicit data-loss caveat attached.

One other constraint is worth planning around. On Linux, if syncing is slow, fails, or produces garbled uploads, the README recommends installing xclip on X11 or wl-clipboard on Wayland, because SyncClipboard uses those tools to read the clipboard. That is a real dependency on the desktop environment, not a bug you can configure away.

Where SyncClipboard is the wrong tool

If you want a clipboard manager on a single machine, SyncClipboard is overbuilt. The history store lives behind a server, and the value comes from moving content between machines. A local-only tool does that job with no server, no credentials and no network.

If you want a first-party mobile app, look carefully before committing. iOS is handled through Shortcuts, Android through SyncClipboard Mobile, Sync Clipboard Flutter, an AutoJs6 script, Fcitx5-SyncClipboard or syncclipboard-xposed, and HarmonyOS Next through ClipLink. Each of those is maintained in its own repository, several by other authors, so the upgrade story spans several projects.

If every machine in your setup must stay on an older release, SyncClipboard is also the wrong tool. The v3.1.1 change is a hard break: newer clients and servers do not interoperate with older ones, and the README requires the whole sync network to move together.

SyncClipboard against CopyQ and the WebDAV-only route

CopyQ is the obvious comparison, and the difference is architectural rather than cosmetic. CopyQ is a local clipboard manager: it keeps history on the machine where it runs. SyncClipboard adds history sync, which is what makes history visible from a second machine.

Within SyncClipboard itself there is a second choice worth naming: standalone server versus WebDAV. The standalone server has its own server configuration and the documented API for getting and uploading the clipboard. A WebDAV drive gives you none of those controls, because you are borrowing someone else's storage semantics; what you get instead is not running a service. The S3 route sits between them: you get object storage you may already pay for.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-10-29. Releases have been frequent: v3.3.0 on 2026-09-25, v3.3.1 on 2026-10-02, and v3.3.3 on 2026-10-18. That cadence cuts both ways. You get fixes, but you also inherit the v3.1.1 incompatibility precedent, which shows the project will break client-server compatibility when it needs to. Budget for upgrading the server and every client and third-party client in the same window.

Clients can also be installed through package managers: WinGet on Windows, Homebrew on macOS and the AUR package syncclipboard-desktop on Arch Linux. On the client side, Windows and macOS installers and Linux packages come from the releases page, so the cost is per-machine rather than per-service.

The project is MIT licensed, and the repository carries a LICENSES/ directory alongside the LICENSE file, which suggests bundled components may carry their own terms. MIT is permissive, but if you redistribute the desktop client or the server inside a product, read the per-component licences in that directory rather than assuming the top-level file covers everything. This is a description of what the repository contains, not legal advice.

Editorial conclusion

Adopt SyncClipboard if you control a server, a WebDAV drive or an S3 bucket and you want clipboard history that stays on infrastructure you own, with Windows, macOS and Linux desktop clients in one sync network. Do not adopt it if you need clipboard history as durable storage: the README warns that the history feature is early stage and tells you to be prepared to lose all of it, so anything important should live elsewhere. Before rolling it out, verify that every client and server in the network is at v3.1.1 or later, because the v3.1.1 change makes older clients and servers incompatible with newer ones.

Frequently asked questions

Official sources

1. Issues
2. Jeric-X/SyncClipboard on GitHub
3. License: MIT
4. README
5. Releases