QR Send vs AirDrop

Direct answer

AirDrop moves files between Apple devices over a peer-to-peer radio link and requires Wi-Fi and Bluetooth enabled on both. QR Send moves files over a unidirectional optical link that a camera reads, so it works between an iPhone and Windows, or two Android phones, with no shared network and no account.

Key takeaways

AirDrop is documented for Apple devices only: both ends need Wi-Fi and Bluetooth switched on, plus a receiving visibility setting.
QR Send needs no pairing, no account and no shared network; the receiver opens a page and points a camera at the sender's screen.
The medium differs: AirDrop builds a radio peer link between two authenticated Apple devices, while QR Send carries bytes as a unidirectional optical stream.
QRTP frames carry 368-byte large packets or 40-byte small packets, and a Wirehair fountain carries up to 64,000 blocks per transfer, so a missed frame costs time rather than a retransmission round trip.
When a network happens to exist, QR Send advertises it over an optical metadata stream and can upgrade the transfer to a WebRTC/PeerJS peer connection.
Where it works, AirDrop stays the faster and better integrated option: no camera alignment, no line of sight, and it is built into the share sheet.

Where AirDrop stops

AirDrop is excellent software with a hard boundary: both devices must be Apple devices. Apple's support documentation describes the setup as turning on Wi-Fi and Bluetooth at both ends and choosing a receiving setting that decides who can see the device. If either end is a Windows laptop, an Android phone or a Linux box, AirDrop is not on the menu, and no configuration changes that.

QR Send starts from the opposite end. The sender displays QRTP frames on its screen and the receiver decodes them with a camera. That channel is optical and unidirectional — the receiving device never transmits — so the two ends need not agree on a radio standard or a network name. The same page runs in a browser on any platform with a camera, and the same protocol ships as a native terminal binary for macOS, Linux, Windows and WASI.

Side-by-side

Dimension	AirDrop	QR Send
Platforms	iPhone, iPad, Mac — Apple devices only	Any device with a browser and camera; native `qrsend` for macOS, Linux, Windows and WASI
What must be enabled	Wi-Fi and Bluetooth on both devices, plus a receiving visibility setting	A screen at the sender and a camera at the receiver
Shared network needed	No — both radios must be on, but the devices do not join a network	No network at all, unless you want the WebRTC upgrade
Receiver setup	Device must be discoverable; the person accepts the incoming item	Open the receive page, point the camera at the screen, scan
Works with the radio off	No; Apple's documented setup requires Wi-Fi and Bluetooth	Yes; the optical link is the only channel
Typical throughput	The faster of the two where it works; Apple's documentation publishes no figure	Set by frame rate, QR count and packet size — two 368-byte packets in each of two QR codes at 20 fps is roughly 29 kB/s of raw blocks before fountain and error-correction overhead
What a bystander could observe	Only what the visibility setting exposes: whether the device is discoverable to contacts or to everyone nearby	Anyone with line of sight and a camera can capture the same frames; Safe Send encrypts the payload so recorded frames stay unreadable

How the bytes actually move

QRTP is not "one QR code per file". It is a stream of frames, each carrying fountain-coded blocks from one of several logical streams, and the receiver rebuilds the original bytes once it has enough distinct blocks.

A frame is either full, carrying explicit stream headers, or squeezed, which implies stream_id = 0 and spends the header bytes on payload instead.
The transfer_id field is 15 bits, and its high bit is what marks a frame as squeezed.
Stream 0 is payload; stream 1 carries the network metadata used for the WebRTC upgrade.
In Wirehair mode a 4-byte block_id prefixes each block, so a 368-byte packet carries 364 bytes of fountain block. Small 40-byte packets exist for low-resolution screens.
If the whole payload fits in one packet, QRTP uses direct mode and skips the fountain.

The WebRTC upgrade

When a network exists on both sides, the sender puts its reachability details into stream 1, the receiver reads them out of the optical frames, and the two endpoints negotiate a WebRTC data channel through PeerJS. Bulk data then moves over the radio at network speed while the QR stream remains the bootstrap and the fallback. This matters when devices share a network but cannot discover each other — a guest VLAN, a locked-down laptop, or a firewall that blocks inbound connections.

Sending from a terminal

The native binary renders the stream into a text terminal, which is the simplest way to feed a machine with no browser open:

./qrsend --fps 20 --cols 160 --rows 60 --ecc 3 \
  --packets-per-qr 3 --qrs-per-frame 2 \
  --label "Scan with the QR Send camera page" archive.tar.gz

tar cf - ./project | ./qrsend --fps 20 --cols 160 --rows 60 -

./qrsend --fps 20 --invert --fg "#ffffff" --bg "#000000" photo-set.zip

The first line streams a file with three packets per QR code and two QR codes per displayed frame; the second reads from stdin, since - means stdin; the third inverts the palette for a dark room. Two settings drive practical speed: frames per second (--fps) and how much data each displayed frame holds (--packets-per-qr, --qrs-per-frame, and the packet size chosen by --ecc). Cameras usually decode best with fewer, larger QR codes per frame. --verbose and --log-audit show what was actually rendered while tuning.

Being fair to AirDrop

AirDrop is faster and better integrated wherever it applies, and saying otherwise would be dishonest. It needs no camera alignment, no steady hand, no bright screen and no clear line of sight; the two devices can sit in a bag. It is wired into the share sheet, Photos, Files and Finder, and handles a whole selection in one gesture.

So the honest summary is about fit, not superiority:

Situation	Better tool
iPhone, iPad and Mac, all with Wi-Fi and Bluetooth on	AirDrop
iPhone to Windows laptop	QR Send
Android to Android, no shared network	QR Send
Machine on a locked-down or isolated network	QR Send
Very large files, both endpoints on fast radios	AirDrop, or QR Send with the WebRTC upgrade
Anything where no radio may be enabled at all	QR Send

If both ends do have internet, a cloud link is often the least effort — see QR Send vs cloud sharing for where that trade-off lands. If the reason you are here is that the radio cannot be trusted or cannot be turned on, the deeper analysis is in optical vs radio transfer security.

FAQ

Can I AirDrop from an iPhone to a Windows laptop?

No. AirDrop is documented for Apple devices, with Wi-Fi and Bluetooth enabled on both ends. For iPhone to Windows, display the file from the phone with the QR Send page and scan it with the laptop's webcam, or run ./qrsend on the Windows machine and point the phone's camera at the terminal.

Does QR Send need Wi-Fi or Bluetooth at all?

No. The optical link is the transport, so the radio can stay off. Wi-Fi only becomes relevant if both devices are already on a network, in which case QRTP negotiates the WebRTC upgrade through the optical metadata stream.

How slow is it compared with AirDrop?

Slower, where AirDrop works. The optical rate is bounded by how many bytes each displayed frame holds and how many frames per second the camera decodes, and fountain plus error-correction overhead reduces goodput further.

What happens if someone walks in front of the camera mid-transfer?

Those frames are lost, but the fountain does not request retransmissions — later blocks cover the missing ones. The transfer takes longer; if the camera loses the screen entirely, re-point it and the receiver keeps collecting.

Who can read the transfer as it goes past?

Anyone with line of sight and a camera can capture the same frames, which is the cost of an optical broadcast channel. Safe Send encrypts the payload with a password before it is rendered, so captured frames stay unreadable without it.