Ditching the Cloud for Good: Why KDE Connect Beats Blip and LocalSend

There is a particular kind of frustration that only surfaces when you try to move a file from your phone to the laptop sitting two feet away. You reach for Bluetooth and remember it does not work between iOS and Android. You reach for AirDrop and remember you are not in Apple’s garden. You reach for a cable and remember the protocol on the other end is MTP, which corrupts large files for sport. So you upload to a cloud service, wait, and download again — sending your data on a round trip to a data centre in another country so it can travel three metres.

A small but growing category of apps exists to fix this. They share a philosophy: transfers happen directly between devices, over your local network, with no cloud relay and no account. Apple’s AirDrop and Google’s Quick Share are the locked-down, ecosystem-bound versions of the idea. The open, cross-platform versions are what this post is about — and three of them dominate the conversation right now: Blip, LocalSend and KDE Connect.

If you already use Blip or LocalSend, you have good taste. Both are excellent at what they do. But they are, in the end, file droppers. KDE Connect is something broader: a bidirectional device-integration platform that happens to include file transfer. After living in all three for a while, KDE Connect is the one that has stuck — and the rest of this post explains why, with the firewall plumbing to make it actually work.

The three contenders, in brief

LocalSend is a free, open-source (Apache 2.0) app built in Flutter with a Rust core. It speaks a documented REST-over-HTTPS protocol, discovers peers with multicast UDP, and works on Windows, macOS, Linux, Android, iOS and Fire OS. No account, no servers, no ads. It is the spiritual successor to Snapdrop/PairDrop, but native and fast.

Blip is a polished, closed-source app from a San Francisco company. It is genuinely quick, transfers over the internet as well as the LAN, resumes interrupted transfers, and preserves folder structures. The price of that convenience is an email-based account and a proprietary protocol running through Blip’s own relay infrastructure. It is free for personal and non-commercial use; commercial use needs a paid Business plan.

KDE Connect is a free, open-source (GPL) project from KDE, older than the other two by a decade and far more ambitious. Rather than just moving files, it exposes a plugin-driven protocol over D-Bus that lets paired devices share clipboards, mirror and reply to notifications, act as remote controls for one another, mount a phone’s filesystem over SFTP, run shell commands, send SMS, and more. It runs on Linux, Android, iOS/iPadOS, Windows (officially) and macOS (nightly), and the protocol has a second, independent GNOME implementation called GSConnect.

Head-to-head comparison

The table below is the bit most people scroll to. Values reflect the current releases as of August 2026.

¹ macOS is an unofficial nightly build; Windows, Linux, Android and iOS are officially supported.

The pattern is obvious: Blip and LocalSend are file-transfer tools that overlap on the “move bits between devices” axis and differ on open-versus-closed and LAN-versus-internet. KDE Connect is a superset on the feature axis and a peer of LocalSend on the open-source, no-account, no-relay axis. The only places Blip and LocalSend clearly win are resumable transfers and out-of-the-box internet reach — real advantages, but narrow ones.

Pros and cons of each

KDE Connect

LocalSend

Blip

A deep dive into KDE Connect

Here is the part where KDE Connect pulls away. The other two apps answer the question “how do I get this file over there?” KDE Connect answers “how do I make these two devices behave like one system?” — and does it without an account, a cloud, or a closed binary.

How it actually works

KDE Connect is split into a UI-agnostic core and a set of UI front-ends. The core exposes D-Bus interfaces and is built from four blocks:

Because features are plugins speaking a defined packet format, the surface is composable: enable what you want, disable what you do not, and write your own if you are so inclined. Everything is wirelessly transmitted with TLS encryption; file browsing uses SFTP. Nothing is sent to KDE or any third party.

Cross-platform, and not locked to KDE

A common misconception is that KDE Connect is KDE-only. It is not.

That reach matters. You are not betting on a single vendor’s roadmap or a single company staying alive. The protocol is open and has more than one implementation.

Firewall settings: making it communicate

This is the one piece of friction, and it is worth understanding rather than copy-pasting blindly. KDE Connect uses a fixed port range — 1714 through 1764 — for both TCP and UDP. UDP carries multicast discovery (devices finding each other); TCP carries the plugin data channels and file transfers. If those ports are blocked, you get the classic symptom: both apps open, neither device sees the other, and turning the firewall off “magically” fixes it.

A couple of network-layer points apply regardless of firewall tool:

UFW (Ubuntu, Debian, Mint, and derivatives) — the quick version:

sudo ufw allow 1714:1764/tcp
sudo ufw allow 1714:1764/udp
sudo ufw reload

UFW — the sane, LAN-scoped version (recommended; do not open 50 ports to the whole internet):

# Find your subnet (look for the 'scope global' inet line)
ip -4 addr

# Allow only from your local subnet, IPv4
sudo ufw allow proto tcp from 192.168.1.0/24 to any port 1714:1764 comment 'kdeconnect'
sudo ufw allow proto udp from 192.168.1.0/24 to any port 1714:1764 comment 'kdeconnect'

# IPv6 link-local
sudo ufw allow proto udp from fe80::/64 to any port 1714:1764
sudo ufw allow proto tcp from fe80::/64 to any port 1714:1764

sudo ufw reload

firewalld (Fedora, RHEL, Rocky, Alma, openSUSE) — using the built-in service definition:

sudo firewall-cmd --permanent --add-service=kdeconnect
sudo firewall-cmd --reload

firewalld — manual port ranges (if the service definition is missing):

sudo firewall-cmd --permanent --add-port=1714-1764/tcp
sudo firewall-cmd --permanent --add-port=1714-1764/udp
sudo firewall-cmd --reload

Always run firewall-cmd --reload after a permanent change; otherwise the runtime and persistent configs drift apart and you will chase phantom bugs.

iptables (manual / minimal systems):

sudo iptables -I INPUT -p tcp --dport 1714:1764 -j ACCEPT
sudo iptables -I INPUT -p udp --dport 1714:1764 -j ACCEPT
# If your OUTPUT policy is restrictive, mirror these for sport 1714:1764

Windows: the installer typically prompts to allow KDE Connect through the firewall for private networks; accept it. If you missed it, add an inbound rule for the KDE Connect executable allowing TCP and UDP 1714–1764 on Private profiles only.

macOS: in System Settings → Network → Firewall, allow the KDE Connect nightly to accept incoming connections, or it will prompt on first run.

When discovery still fails (manual pairing by IP): if multicast is blocked — a corporate LAN, a tricky VPN, or a segmented network — skip discovery and pair by IP. On the desktop, add a customDevices line to the KDE Connect config:

# Linux: ~/.config/kdeconnect/config
# Windows: %LOCALAPPDATA%\kdeconnect\config
[General]
name=mydesktop
customDevices=192.168.1.42,192.168.1.43

On Android, use the three-dot menu → “Add devices by IP”. For VPN use, a bridged OpenVPN (TAP) setup preserves multicast and works like a local network; a routed (TUN) setup needs the manual-IP approach above. Bluetooth pairing is also available as a transport since v24.08.1 if Wi-Fi is awkward.

Verifying it is listening

Once the daemon is running, confirm it has actually bound the ports:

systemctl --user status kdeconnect
ss -tulnp | grep -E '171[4-6]'

If ss shows nothing on 1714–1764, another process may be holding the range (check with sudo lsof -i :1714-1764), or the daemon did not start — journalctl --user -u kdeconnect -n 20 will tell you why.

What you can actually do with it

This is the part where the abstraction of “device integration” turns into something you can actually feel, and where KDE Connect stops being a file-transfer app you are evaluating and starts being something you reach for without thinking. The features group roughly into a handful of themes, but the through-line is the same: every one of them removes a small, stupid, recurring friction between your phone and your computer, and the sum of those removals is a noticeably better day.

Sync and messaging

Start with the clipboard, because it is the feature people fall in love with first. Copy a paragraph, a URL, a phone number, a two-factor code on your laptop, and it is sitting on your phone’s clipboard the instant you pick it up — and the reverse is just as true. It sounds trivial until the first time you copy a one-time password from your password manager on the desktop and paste it straight into the banking app on your phone without a single retyping or a glance at a screen. It is bidirectional, it is instant, and it quietly deletes a whole category of “ugh, I’ll just text it to myself” moments from your life. The one caveat is that Android 10 and later forbid background apps from reading the clipboard, so pushing from phone to PC is not quite automatic any more — you use the “Send clipboard” action in the persistent notification or, on Android 14 and up, a quick-settings tile. It is a one-tap tax imposed by the OS, not by KDE Connect, and once it is muscle memory you stop noticing it (KDE UserBase).

Layered on top of that is notification sync, which is the feature that genuinely changes how you work at a desk. Your phone’s notifications — messages, emails, app alerts, calendar reminders — materialise on your computer as native desktop notifications, and where the app allows it you can reply to them right there from the keyboard, without unlocking your phone, without picking it up, without breaking your flow. A WhatsApp or Signal message arrives; you type a reply and hit enter; the phone in your pocket sends it. Your phone stays face-down and silent while you concentrate, and you miss nothing. Taken further, the SMS plugin gives you a dedicated desktop app for your text messages and MMS: read, compose, and reply from a real keyboard, with your phone acting as the dumb transport in the background. It is the experience iMessage-on-Mac gives Apple users, and KDE Connect gives it to everyone, with any carrier, on any desktop. Rounding out the theme, contacts quietly sync from your phone to your desktop in vCard form (one-way, consumed by KDE’s KPeople framework), and you can fling a URL or link from one device to another and watch it open in the other’s browser — perfect for “I’ll read that on the big screen” or “let me open that on my phone to go.”

Remote control

If sync and messaging make your phone less of an interruption, remote control turns it into an instrument. The simplest expression is the virtual touchpad and keyboard: open it on your phone and your phone’s screen becomes a laptop trackpad, with two mouse buttons, two-finger scroll, tap-to-click, and the full soft keyboard feeding keystrokes to whatever text field has focus on your PC. It is the emergency input device you never knew you needed — brilliant for leaning back on the sofa to drive a media PC, for presenting, for nudging a cursor when your real mouse has died, or for typing into a headless box without reaching for a keyboard. It works in reverse, too: from the desktop you can drive the pointer on your phone and type with your physical keyboard, though Android only accepts keyboard input from one app at a time so you switch inputs to make it seamless. There is even a gyro mouse that lets you tilt the phone to move the pointer, which is surprisingly usable when the phone is lying flat on a desk.

From there it gets more purposeful. The multimedia remote turns your phone into a proper controller for whatever is playing on your computer — play, pause, skip, seek five seconds either way, and adjust both per-application and system volume, with a picker to choose which media player you are driving. Paired with KDE’s Plasma Browser Integration, that same remote reaches into your browser and controls YouTube, Netflix, PeerTube or anything else playing in a tab, which is when it stops being a novelty and becomes the thing you actually use to pause a film from across the room. For the slide-deck crowd there is a dedicated presentation remote that advances your slides from your phone and — the genuinely delightful touch — uses the phone’s gyroscope to drive an on-screen pointer that behaves like a laser pointer, so you can gesture at a chart on the projector from anywhere in the room. No hardware clicker, no battery to forget, no dongle to lose. And then there is Run Commands, the power user’s favourite: define a list of shell commands on your computer — lock the screen, suspend the machine, toggle a keyboard layout, launch an app, kick off a backup, mute the audio — and trigger any of them with a tap from your phone. It is a tiny, encrypted, authenticated remote control for your own machine that you design yourself (example commands), and it is the feature that, more than any other, is why technical users never go back.

Files and media

File transfer is here too, of course, because KDE Connect does that as well as the dedicated file droppers — but it does it as part of a bigger picture. You can push files either way, received files land in your Downloads folder by default, and the whole thing is wired into the Android and iOS share sheets and the desktop file manager’s share menu, so “share to KDE Connect” is always one tap away wherever you are. Where it pulls ahead of the file-only apps is the SFTP plugin: enable it and your phone’s storage mounts over SFTP and shows up in your file manager like any other remote directory, so you can browse it, copy off a batch of photos, drop on some music, or dig through a nested folder structure as though the phone were a USB drive that never asked for a cable. MTP, with its legendary talent for corrupting large files, is simply no longer in your life. And with Plasma Browser Integration installed, you can send the browser tab you are looking at on your desktop straight to your phone — the modern equivalent of emailing yourself a link, minus the email.

System, power and quality of life

The last cluster is the set of small, thoughtful touches that, individually, sound trivial and, collectively, are why KDE Connect feels finished. Your phone’s battery level sits next to your computer’s in the panel, so you glance at one place to know both. A “find my phone” command rings your phone at full volume from the desktop — the feature that pays for itself the first time the device slides down the back of the couch. When a call comes in, music and videos pause automatically and resume when you hang up, a small dignity that, combined with browser integration, means a YouTube video does not keep blaring through your earbuds while you answer the phone. A “pause media during calls” toggle sounds like nothing until you have lived with it, and then you cannot imagine giving it up. The screensaver inhibitor keeps your screen awake while a device is connected, so a long file copy or a remote-control session is not interrupted by a lock screen, and the Trusted Networks feature lets you whitelist the Wi-Fi networks where KDE Connect is allowed to be active, so it stays silent and invisible on the guest network at a café and only wakes up on your home and office networks. None of this is glamorous. All of it is the difference between a tool you installed and a tool you rely on.

From the command line

For the technical audience this post is written for, though, the quiet killer feature is kdeconnect-cli — because everything above is also a command you can type, pipe, schedule, and wire into the rest of your system. The whole device relationship becomes scriptable:

# List paired devices and their IDs
kdeconnect-cli --list-devices

# Ping a device to check reachability
kdeconnect-cli --device <id> --ping

# Send a file
kdeconnect-cli --device <id> --share /path/to/file.pdf

# Ring a misplaced phone
kdeconnect-cli --device <remote-phone-id> --ring

# List and trigger remote commands defined on the other device
kdeconnect-cli --device <id> --list-commands
kdeconnect-cli --device <id> --execute-command <command-id>

That last combination — Run Commands defined on the desktop, --execute-command fired from another machine — is the bit that quietly rewrites what the app is. It is a tiny, TLS-encrypted, authenticated remote-control channel that you define yourself, with no relay in the middle and no account in the way. Drop it into a shell alias, a cron job, a Home Assistant automation, a shortcut on a second phone, a CI step that pushes a build artifact to your handset, or a recovery script that rings your missing phone and locks its screen at the same time — and you have built something the file-only apps not only cannot do, but cannot even conceive of. KDE Connect is not just a way to move files. It is a programmable bridge between every device you own, and once you start treating it that way, the file-transfer apps start to look like the warm-up act.

So why is KDE Connect the best?

For the kind of person who chose LocalSend over AirDrop — someone who values open source, local-first operation, no accounts and no telemetry — KDE Connect is the logical endpoint of that same philosophy, applied to the whole device relationship rather than just file movement. You keep every property that drew you to LocalSend (open, auditable, serverless, TLS-encrypted, cross-platform, free) and gain a decade of integration work on top: clipboard, notifications, remote control, SMS, SFTP, scripting.

Blip is the right answer if your top priority is “send a 40 GB folder to a colleague on another continent and resume it when the connection drops.” It is a superb file mover. But it is closed, account-gated, relay-dependent and commercially licensed — the opposite of the values that make LocalSend appealing — and it does nothing beyond files. LocalSend is the right answer if you want the simplest possible open-source LAN file drop and nothing else.

KDE Connect is the right answer when you want your phone and your computer to stop being polite strangers. The one-time cost is a firewall rule and five minutes of pairing; the payoff is a workflow you will notice every single day. For a technical audience already comfortable with a terminal and a firewall, that trade is a gift.