qrcp

Last reviewed Aug 26, 2026 · 733 words

qrcp send backup.tar.gz, point the phone camera at the terminal, tap, done. That is the entire product. qrcp starts a temporary web server on your machine, prints a QR code containing its URL, and shuts the server down when the download finishes. It is a single static Go binary of about 10 MB, it needs nothing installed on the phone, and it has been the fastest way to get a file from a headless server to a phone in my toolkit for years. The rest of this guide is its 3 limits and the 1 config file that removes the daily friction.

One command each way

qrcp send file (or just qrcp file) serves a download. qrcp receive does the reverse: the QR code opens a plain upload page on the phone, and whatever you pick lands in the current directory. Send several files or a directory and qrcp zips them first, or pass --zip to force it for a single file. By default the server exits after 1 transfer; --keep-alive keeps it up for the next person in the room. The URL includes a random path, so a neighbour on the same network who guesses your IP and port still gets nothing without the code.

Set the interface once and stop answering prompts

With several network interfaces, qrcp asks which one to use every time, and that is the first thing to fix. Install it with brew install qrcp, go install github.com/claudiodangelis/qrcp@latest, or a binary from the GitHub releases page, then run qrcp config once. It walks you through the choices and writes a small YAML file under ~/.config/qrcp/:

interface: wlan0
port: 8080
keepAlive: false

A fixed port matters more than it looks: it lets you open exactly 1 firewall rule (ufw allow 8080/tcp) instead of disabling the firewall in frustration when the phone spins forever. On a server you reach over Tailscale, set interface: tailscale0 and put the phone on the same tailnet, and the QR code works from anywhere on earth, which is the trick that turns a LAN toy into something I use weekly.

Three limits worth knowing before you rely on it

First, same network. The phone must be able to reach the address in the code, and guest Wi-Fi with client isolation, corporate networks, and most hotel networks block exactly that. Tailscale is the fix; there is no relay to fall back on. Second, plain HTTP. On your own LAN that is fine. In a café it means anyone on the network can read the file in transit; --secure with your own certificate closes that, but the phone then has to trust the certificate, which is more work than it sounds. Third, it is a terminal tool with no daemon and no discovery. It cannot send phone to phone, it cannot run in the background waiting for files, and it will not sync anything. Those are not omissions; they are the reason it is 10 MB.

Where it sits next to LocalSend, PairDrop, and Syncthing

LocalSend is what to install on the phones themselves: an app at both ends, automatic discovery, encryption by default, and phone-to-phone transfers, at the cost of needing the app everywhere. PairDrop is browser-to-browser and needs nothing installed, but relies on a signalling server (self-hostable) and both devices having a browser open. Syncthing is continuous folder sync and belongs to a different problem entirely. qrcp's niche is precise: you are in a terminal, often over SSH on a machine with no desktop, and you want 1 file on a phone in the next 15 seconds. None of the other 3 do that as well, and qrcp does nothing else.

What I'd do

Install qrcp on every server and laptop I touch, run qrcp config once per machine with the Tailscale interface and a fixed port, and open that port in the firewall. Keep LocalSend on the phones for everything that starts on a phone. Never use qrcp on a network I do not control without --secure, and for anything that needs to arrive on a schedule rather than in a hurry, use Syncthing. It is a 10 MB binary that solves 1 problem completely, and that is the highest compliment I have for a command-line tool.