ClipHop vs KDE Connect: when to pick which for Android–Mac clipboard sync

If you use an Android phone with a Mac and care about clipboard sync, two serious non-cloud options exist: KDE Connect and ClipHop. They share almost nothing architecturally — KDE Connect runs over LAN / WiFi, ClipHop runs over Bluetooth LE — and each is the right answer for a different set of constraints.

This post is an honest side-by-side. We built ClipHop because we wanted something KDE Connect doesn’t do; we still think KDE Connect is excellent for the scenarios it targets. Here’s how to pick.

What each tool actually is#

KDE Connect is a cross-platform sync framework from the KDE project. It’s open-source, actively maintained, and does much more than clipboards — notifications, file transfer, media control, battery status, remote input, SMS mirroring, shared browser tabs. It runs as a long-lived service on both devices, speaks a JSON-over-TLS protocol, and discovers peers over mDNS on the local network.

ClipHop is a single-purpose tool that only does clipboard sync between one Android phone and one Mac. It runs over Bluetooth LE (no network required), uses X25519 ECDH for per-reconnect session keys on AES-256-GCM, and authenticates with Ed25519 identity keys stored in the Keychain / Keystore. See How ClipHop encrypts your clipboard for the cryptographic detail.

That “only does clipboard” choice is deliberate. Clipboards are the highest-value-per-byte data that moves between devices, and they deserve a focused tool.

Transport differences that actually matter#

The LAN requirement is KDE Connect’s one real limitation, and it’s a bigger one than it used to be:

• Home networks are now commonly mesh-based with client isolation between devices.
• Hotel and coffee-shop WiFi almost always has client isolation on.
• Corporate networks segment devices by role — personal phone and laptop often can’t reach each other.
• Travel workflows that cross networks break the pair constantly.

If you’re always on the same stable WiFi (a home network with a simple router, say), KDE Connect works beautifully. If you cross networks regularly, it falls over.

BLE doesn’t care about any of that. Two paired devices find each other and connect whenever they’re in radio range. The trade is range (~10–15 m instead of whole-building) and throughput (fine for text, slow for large files).

Feature surface: broad vs focused#

KDE Connect does a lot:

• Clipboard sync (both directions)
• Notification mirroring (phone → desktop)
• File transfer
• Remote input (use your phone as a trackpad)
• Media control (pause/play on desktop from phone)
• Battery level display
• Remote commands / SMS mirroring / shared browsers on Linux
• Ring-my-phone, find-my-device

ClipHop does one thing:

• Clipboard sync (both directions)

That’s it. Nothing else. No file transfer, no notifications, no remote control. If you want broad cross-device sync, KDE Connect’s feature surface is probably what you want and ClipHop won’t cover it.

If clipboard is your real pain point — the 80% of cross-device moves you actually do — a single-purpose tool has advantages: smaller attack surface, fewer permissions, clearer mental model, no “why is it using battery?” moments because the only background work is the clipboard.

Security model#

Both tools are honest about their model but the details differ.

KDE Connect:

• TLS 1.2+ between devices with certificate pinning (after first-pair).
• Pairing is accept-prompt based (“Device X wants to pair”).
• Per-pair long-term certificates stored locally.
• No external trust dependency — but also no user-visible fingerprint to re-verify ongoing.

ClipHop:

• X25519 ECDH per reconnect produces a fresh AES-256-GCM session key via HKDF.
• Ephemeral key exchange signed by long-term Ed25519 identity keys in the Keychain / Keystore.
• Identity fingerprint displayed to user — verify at pair time and any time after from Paired Devices (Android) / Preferences → Security (Mac).
• Forward secrecy across sessions.

The fingerprint-verification model is the one meaningful security difference. KDE Connect is secure enough for most threat models but doesn’t give you a way to check cryptographically that today’s peer is the same peer you paired with yesterday. ClipHop’s fingerprint is exactly that check — ongoing MITM detection rather than a one-shot accept-and-trust.

Setup effort#

KDE Connect: install both apps, they discover each other on the LAN, accept the pair prompt on both sides. Works immediately if you’re on the right network.

ClipHop: install both apps, scan a QR code (or enter a 6-digit code) once, compare fingerprints, done. Pairing persists across restarts and reconnection is automatic.

Roughly equivalent setup friction. KDE Connect is slightly simpler if you’re on a compatible network; ClipHop is slightly more explicit and gives you a fingerprint to verify.

Resource cost#

On Android specifically, both tools need permissions that non-background apps don’t:

• KDE Connect runs a foreground service for notifications and maintains TCP connections. Moderate-to-high battery impact depending on activity.
• ClipHop runs a foreground service to keep the BLE link alive across screen-off. BLE is radio-efficient relative to WiFi — real-world battery impact is minor.

On Mac, both are menu-bar apps with negligible CPU at idle.

When to pick which#

Pick KDE Connect if:

• You want broad cross-device sync (notifications, files, media control, remote input), not just clipboard.
• Your devices are always on the same WiFi network.
• You’re comfortable with the “accept the pair prompt” trust model and don’t need fingerprint verification.
• You prefer fully-open-source, community-audited software today (KDE Connect is FOSS; ClipHop isn’t open-source yet but the crypto is documented).

Pick ClipHop if:

• Clipboard sync specifically is your pain point.
• You travel, co-work, or use coffee-shop WiFi — anywhere that “same LAN” is unreliable.
• You want end-to-end encrypted clipboard sync with a verifiable identity fingerprint.
• You want a small tool that does one thing and doesn’t sit in the background running protocols you don’t use.

Run both if:

You can. They don’t conflict. A common setup: KDE Connect at home for file transfer and notifications, ClipHop everywhere — including at home — because it works before the WiFi does, and the fingerprint model gives you stronger verification for the clipboard specifically.

The shortest version#

KDE Connect is a cross-device sync framework that happens to include clipboards. ClipHop is a clipboard tool that happens to use Bluetooth. Pick the one whose shape fits your actual use.

If you decide ClipHop is worth trying: download the Mac app, grab the Android app from the Play Store, and the 60-second setup guide will have you pasting across devices in one cup of coffee. For the transport reasoning, see Why Bluetooth LE. For the comparison to Apple’s side of the world, see Universal Clipboard for Android.