Last updated·
You copied a long URL on your Mac. You want to paste it on your Windows desktop, or your Linux box at home. The “solutions” people end up using are surprisingly bad:
You copied a long URL on your Mac. You want to paste it on your Windows desktop, or your Linux box at home. The “solutions” people end up using are surprisingly bad:
None of these were designed to sync a clipboard. Some of them are also a bad fit for the kind of stuff that actually shows up in your clipboard — passwords, API keys, internal URLs, half a paragraph of a draft.
This page is about the narrow gap UniClipboard is built for: clipboard sync across Mac, Windows, and Linux, with no cloud account, no self-hosting, and end-to-end encryption across the public internet.
To be precise upfront: “no cloud account” does not mean “no network”. Devices try to talk directly via P2P. When the network refuses to cooperate, traffic falls back to an encrypted relay. The relay can route bytes; it cannot read your clipboard.
“DM myself on Telegram” works for one URL. After that it falls apart in small but irritating ways.
The worst part is that it trains you to ignore the cost. After a while you forget how many tokens, paths, snippets, and half-thoughts you have quietly piped through Telegram or WhatsApp because you needed them on another machine for thirty seconds.
A clipboard sync tool should make that habit unnecessary.
Hosted clipboard services in the “sign up, install, sync” shape have one structural problem: at some point your clipboard exists on someone else’s server, in a form that someone other than you could be in a position to read.
That might be fine for grocery lists. It is genuinely not fine for:
Most of what is in a clipboard is mundane. The risk is that a small fraction is not, and you cannot easily separate the two in real time. So the question becomes: do you trust a third-party service with the union of all of it, including the stuff you would never have uploaded on purpose?
“We encrypt your clipboard” is not the same as “we cannot read your clipboard”. The interesting question is which keys live where, and what the server-side software could do if it wanted to (or if it were forced to).
UniClipboard’s position on this is intentionally narrow: clipboard payloads are encrypted on your device with a key the relay does not have, and they are decrypted on the receiving device. The transport layer — direct or relay — never holds plaintext.
The next instinct, especially in self-hosting circles, is: just run a server.
Self-host a sync server, point all your devices at it, done. That is genuinely the right answer for some people, and there are good open-source projects in that shape.
For most people who only want their clipboard to follow them across three desktops, it is too much:
Self-hosting earns its keep when you are also the kind of person who likes running the thing. Otherwise, the clipboard quietly turns into another homelab chore.
UniClipboard sits between “DM myself” and “run my own server”. The shape is:
A few things matter about this:
Pairing, not login. There is no UniClipboard account. Your “identity” for the network is your paired devices. If you stop trusting one, you unpair it.
No central clipboard database. Your clipboard does not live on a UniClipboard server, because there is no UniClipboard clipboard server. Each device keeps its own encrypted local history.
Direct P2P when the network allows it. When two devices can reach each other directly (same LAN, friendly home network, working hole-punch), traffic does not go through any relay at all.
Encrypted relay only as fallback. When direct P2P fails — and on real-world networks, it sometimes does — the relay stitches the connection. The relay sees:
The relay does not see:
That is a deliberate split: the convenience of accountless cross-internet sync, without giving a server the ability to read your clipboard.
UniClipboard runs on macOS, Windows, and Linux as a native desktop app, built with Rust and Tauri 2.
What it does not do today:
The install path is intentionally short:
There is no “create an account” step, because there is no account. There is no “configure server URL” step, because there is no server you have to point at.
If pairing happens on the same LAN, the first connection is usually direct. If your devices are on different networks, UniClipboard will hole-punch where it can, and fall back to the encrypted relay where it cannot.
A short, practical sweep — not a takedown, just where each shape fits.
This kind of product depends on you being able to check claims, not just believe them.
UniClipboard is open source. The crypto stack uses well-reviewed primitives — no rolled-your-own crypto. Local storage is encrypted at rest. The transport layer is independent of the encryption layer, so the relay’s role is structurally limited to moving ciphertext.
If you care about the details:
None of that replaces a third-party audit. It does mean the design is set up so that the trust surface stays small and inspectable.
If you need clipboard sync to your phone today, or you specifically want to operate a server, this is not the right tool — and we would rather say so than try to talk you into the wrong shape.
No. It means there is no UniClipboard cloud account, no central clipboard database, and nothing to sign up for. Devices still need to reach each other over the network. They try direct P2P first, and fall back to an encrypted relay when direct connection is not possible. The relay only sees ciphertext.
No. Clipboard payloads are encrypted on the source device with a key the relay does not have. The relay sees encrypted bytes, peer IDs, and traffic metadata like byte counts and timing. It does not see clipboard content, clipboard type, device names, or the pairing passphrase.
You can. Tailscale is great. The cost is that every device needs Tailscale installed and configured, every machine joins the same tailnet, and you still have to wire up cross-platform clipboard APIs and a history layer yourself. UniClipboard tries to be a one-install answer to the same problem, with no separate networking product to set up.
Often, yes — that is exactly the case the relay fallback is for. When direct P2P fails (which happens on hostile NATs, locked-down corp networks, and some mobile tethering), the encrypted relay carries the ciphertext between devices. You do not have to set up a VPN tunnel between the two networks for this.
Yes. Alongside the macOS, Windows, and Linux desktop apps there is a native Android app (signed APK) and an iOS public beta on TestFlight. If you prefer not to install a native app, the SyncClipboard open protocol still works over LAN via iPhone Shortcuts or a SyncClipboard-compatible Android client.
History is stored locally on each device, encrypted at rest. New clipboard items sync between paired devices, but each device keeps its own searchable history rather than every item being mirrored to a central place.
Deliberate. AGPL prevents anyone from forking the project into a closed-source hosted service that quietly weakens the privacy guarantees and keeps those changes private. For a product whose value depends on a privacy claim, the license is part of how that claim is enforced.
If your clipboard problem really is “Mac plus Windows plus Linux, no cloud account, no server”, this is what UniClipboard is built for.
Pair two devices, copy something on one, paste it on the other. If it stops feeling like a chore, that is the point.