It's not a bug. mDNS, the protocol LocalSend uses to find devices, doesn't cross routers. Here's why - and what actually works when your phone and laptop aren't on the same network.
What's actually happening
1. LocalSend uses mDNS for discovery
mDNS (multicast DNS, RFC 6762) is the protocol that lets devices announce themselves on a local network. Apple's Bonjour, Linux's Avahi, and Windows' built-in multicast all use it. LocalSend sends a multicast packet that says "hi, I'm here" - and other LocalSend instances on the same subnet hear it.
2. Multicast doesn't leave the subnet
Multicast packets have a TTL (time-to-live) of 1 by default. They reach every device on the local network segment - and stop at the router. They don't cross to other subnets, other VLANs, or other networks. This is by design - it's why mDNS doesn't flood the entire internet.
3. So if your devices aren't on the same subnet, they can't see each other
If your phone is on cellular and your laptop is on WiFi: different networks, mDNS can't bridge. If both are on the same WiFi but one is on a guest network: different subnets, still blocked. If hotel WiFi has AP isolation on (most do): same subnet but the router refuses to forward client-to-client traffic.
When LocalSend fails specifically
Phone on cellular, laptop on WiFi
Different networks entirely. mDNS can't bridge. LocalSend will not see either device.
Hotel WiFi with AP isolation
Most hotel networks isolate clients from each other to prevent attacks. mDNS packets are dropped at the access point. Common; nearly universal.
Corporate/office WiFi
IT typically blocks multicast and segments VLANs. LocalSend won't find anything beyond your own laptop.
Guest network
Almost always isolated from the main network and from other guests.
VPN active on one device
VPN tunnels traffic to a remote endpoint - the local network is no longer where multicast goes.
Different SSIDs in a building (eduroam, etc.)
Often the same physical access points but different logical networks. mDNS doesn't cross.
What actually works: skip discovery entirely
The structural problem is that LocalSend assumes "if devices can hear each other on the network, they can transfer." When the network doesn't let them hear each other, LocalSend has nothing to fall back on.
chirpfile uses a different model: the file goes over the regular internet to a relay, and the decryption key travels between the two devices as sound. No network discovery happens at all. The two devices don't need to be on the same network. They don't need to be on any of the same anything. They just need to be in earshot.
That means: phone on cellular and laptop on hotel WiFi can transfer. Two devices on opposite sides of corporate AP isolation can transfer. A guest network and the main network can transfer.
An honest comparison. LocalSend is faster and free for same-network transfers - use it when it works. chirpfile is for the situations LocalSend can't handle: cross-network, hotel WiFi, AP isolation, corporate VLANs, cellular-to-WiFi. The two tools solve different problems.
Try it now
Open chirpfile.com on both devices. No app. No discovery.
Is there a way to make LocalSend work across networks?
Not really. Some routers support mDNS reflection (forwarding multicast between subnets) but it requires admin configuration and only works within your own infrastructure. On hotel, corporate, or guest networks, you can't change the router settings.
Does chirpfile work when both devices are on the same WiFi too?
Yes. It doesn't care what network you're on. The acoustic key transfer happens regardless. But for same-network transfers, LocalSend will usually be faster - that's its strength.
Does the server see my file?
No. The file is encrypted in your browser before upload. The key is transmitted as sound between devices and never touches the server. A separate audit panel at the bottom of every chirpfile page lets you verify this in real time.
What's the file size limit?
Free tier is 15 MB. Pro tier is 1 GB. There's no limit on text/passwords/codes - those go via pure sound, no relay involved.
Why does the receiving device need internet?
To download the encrypted blob from the relay. Both devices need some internet path - it doesn't have to be the same network. Cellular works, WiFi works, anything that reaches the relay works.