KDE Connect: pairing phones and desktops over the local network

What KDE Connect actually solves, and for whom

The README describes KDE Connect as a multi-platform app that lets your devices communicate, giving the example of a phone and a computer. The concrete jobs it names are shared clipboard between devices, notification sync with reply from the desktop, file and URL transfer with some filesystem integration, multimedia remote control for Linux media players, a virtual touchpad and keyboard, a presentation remote, running shell commands on the computer from the phone, and reading, sending and replying to SMS and MMS from the computer. All of it is done wirelessly using TLS encryption.

The audience is narrower than the feature list suggests. The desktop application is written in C++ against Qt 6, and the README's supported platform list leads with computers running Linux with Plasma, GNOME, elementary OS or any distro with Qt 6 support. Android and iOS are covered by separate apps installed from app stores, and Windows users are pointed at the Microsoft Store. If you are looking for a cross-platform desktop tool with an equal first-class build on every OS, this is not that; the Linux desktop is the reference target and everything else is downstream of it.

The DBus core, link providers and the NetworkPacket format

The architecture section of the README is the most useful part of the repository documentation. KDE Connect splits into a UI-agnostic core library that exposes a series of DBus interfaces, plus several UI components that consume those interfaces. The stated reason is that new UI components can be added for a specific platform or desktop without reimplementing the protocol or the internals. In practice that means the daemon, the Plasmoid, the CLI and the file manager integrations are all clients of the same DBus surface rather than separate implementations.

The core is divided into four blocks. LinkProviders discover other KDE Connect-enabled devices on the network and establish a Link to them. Devices represent a remote device and abstract whichever Link reaches it. NetworkPackets are JSON-serializable, self-contained pieces of information exchanged by plugins between devices. Plugins are independent pieces of code implementing one feature, and they exchange NetworkPackets with the matching plugin on the remote device.

A packet has an id, a type, a body and a version. The README shows the shape directly:

How packets, payloads and plugin agreement fit together

The README gives this example of the basic NetworkPacket structure:

{
  "id": 123456789,
  "type": "com.example.myplugin",
  "body": {  },
  "version": 5
}

The body is defined by each plugin, so only the emitting and receiving plugins for a given packet type need to agree on its contents. That is a deliberately loose contract, and it is the design decision worth noticing: the core does not validate plugin bodies, so a version mismatch between a phone app and a desktop build surfaces inside the plugin rather than at the transport layer.

Binary data cannot be serialized to JSON, so packets carrying it add two fields. payloadSize is the size of the file, or -1 for a stream without known size. payloadTransferInfo is another JSON object where the specific Link can put information so the Link at the remote end can establish a connection and receive the payload, for example an IP and port on a local network. The README states plainly that it is up to the Link implementation to decide how to use that field. That is flexible, and it also means the README cannot tell you what a given Link will do with it.

Installing on Linux and pairing a first device

The README's install section is short and distribution-first. On Linux you look in your distribution repository for a package called kdeconnect-kde, kdeconnect-plasma, just kdeconnect, or kde-connect. The naming varies by distribution, which is the first thing to check before assuming the package is missing.

# Debian and Ubuntu naming
apt install kdeconnect

# Fedora naming
dnf install kdeconnectd

The README names the package candidates rather than these exact commands, so confirm the package name against your own repository before running anything. If no package exists, the README points to build-from-source instructions at community.kde.org/KDEConnect under Linux_Desktop, and notes that this repository is the source in that case.

The desktop half is only half the system. The README states that you also need to install the app on your Android device and pair the two in the app before using this application. Android installs come from the Play Store or F-Droid. Pairing is done in the app, not from the command line, and the repository's cli directory suggests a command line client exists for the desktop side, though the README does not document its usage. What you should see after pairing is the device appearing in the desktop UI and the enabled plugins becoming active; the README does not describe the pairing screen itself, so the KDE Userbase wiki it links is the place to look for that.

Where KDE Connect is the wrong tool

The README is explicit that platforms other than Linux are not officially supported, because there has yet to be an official release of KDE Connect for MacOS or Windows. Windows users are told to install from the Microsoft Store, while the same section says most features have already been ported to Windows and that you can compile it yourself using Craft. Those two statements sit awkwardly together, and a reader should treat the Windows path as usable but not officially released. For macOS the README says it has not yet been completely tested and invites contributions and feedback. That is not a supported platform by any normal reading.

BSD gets one line: it should work, but no promises. Nothing in the README describes a remote or relayed connection path; the payloadTransferInfo example is IP and port on a local network, which points at LAN-only operation. If your phone and desktop are routinely on different networks, the documentation gives you nothing to work with. There is also no documented rollback or downgrade procedure, and the repository has no published releases, so version-to-version compatibility between the desktop package and the Android app is something you find out by running them.

Alternatives and the difference in approach

The obvious comparison is a cloud-synced clipboard and notification service, where both devices authenticate to a server and the server relays messages. KDE Connect inverts that: devices discover each other on the local network through LinkProviders and talk directly, with TLS encryption and no account in the middle. The trade-off follows directly. You get no dependency on someone else's uptime and no data leaving your network, and you lose the ability to work when the two devices are not on the same network.

A second comparison is a plain file-sync tool. Those move files between directories on a schedule or on change, and they do not carry clipboard state, notification replies, SMS, or input events. KDE Connect's plugin model is what makes those extra channels possible: each feature is a plugin exchanging NetworkPackets, and the same transport carries a file payload through payloadTransferInfo. If your only need is keeping a folder in sync, a file-sync tool does that with less moving parts. If you need the phone and the desktop to behave as one machine, the plugin approach is the reason to pick this.

Licence, contributions and the maintenance picture

The README states the licence as GNU GPL v2 and GNU GPL v3, and the repository contains a LICENSES directory alongside a REUSE.toml, which is the convention for per-file licence metadata. The practical implication for anyone embedding this in a product: GPLv2 and GPLv3 are copyleft, so distributing a modified binary carries source obligations. That is a description of the stated licence, not legal advice, and the README does not resolve which of the two versions applies to which files.

The repository is not archived, and the last push was on 2026-09-23. Development is visible in the top-level layout: app, cli, core, daemon, plugins, tests, and separate integration directories for the Plasmoid, KIO, Nautilus and file item action plugin. Contributions go through KDE's GitLab at invent.kde.org, and the README asks that bug reports go to KDE's Bugzilla rather than the GitLab issue tracker, so everything stays in one place. Translations are handled by the KDE localization team, not through merge requests against the po directory. If you are reading the project on GitHub, the README says that is just a mirror of the KDE Project repo, which matters when you are deciding where to file something.

Editorial conclusion

Adopt KDE Connect if your devices sit on the same local network and you want clipboard, notification, file and SMS traffic between a phone and a Linux desktop without a cloud account. Do not adopt it if you need a documented remote connection path, a supported macOS build, or a stable protocol for third-party clients; the README states that platforms other than Linux are not officially supported and that the MacOS port has not been completely tested. Before relying on it, verify that your distribution ships a package named kdeconnect-kde, kdeconnect-plasma, kdeconnect or kde-connect, and confirm on the Android side that the app is installed from the Play Store or F-Droid and paired, because the desktop half alone does nothing.

Frequently asked questions

Official sources

1. Issues
2. KDE/kdeconnect-kde on GitHub
3. Project website
4. README