Direct answer
QR Send moves files and live media between two devices by streaming fountain-coded QR codes from one screen to another camera. There is no network path, no account and no upload. Three entry points exist: the browser app at qr-send.com, any phone camera acting as a receiver, and the standalone qrsend terminal binary.
Key takeaways
- QR Send is a sender/receiver pair built on QRTP: a screen emits a stream of QR frames, a camera scans them, and the original bytes are reassembled on the far side.
- The payload is fountain-coded with Wirehair, so the receiver does not need specific frames — any sufficient subset of scanned packets reconstructs the data.
- Packets are 368 bytes (large) or 40 bytes (small); in Wirehair mode each block carries
packet_size − 4payload bytes because a 4-byteblock_idis prefixed to every block. - A single transfer can use up to 64,000 fountain blocks, while a payload small enough to fit in one packet skips fountain coding entirely in direct mode.
- Live media is encoded by MediaRecorder at roughly 200–300 kbps and about 360p, with the fragments appended into Media Source Extensions on the receiving side.
- Nothing is stored server-side: there is no cloud storage, no account and no upload step — the optical link is the whole transfer.
What QR Send does
QR Send is a transfer tool for the case where two devices exist but a usable network path does not. One device plays a sequence of QR codes on its screen; the other watches that screen with a camera and rebuilds the data. Four transfer types sit on top of that mechanism:
- File send — any file is streamed as a fountain-coded sequence of QR frames.
- Safe Send — the payload is AES-encrypted before it is fountain-coded, so the receiver needs the password to decrypt the recovered bytes.
- Live media — a camera, a microphone, or a local audio/video file is encoded on the fly and streamed as live QR payload rather than as a finished file.
- Multi-file and folder transfers — several files, or a whole directory tree, are packed into an archive automatically and sent as one transfer.
Because the data leaves one screen and enters one camera, the transfer works between machines that share nothing else. That is the property that makes it useful in air-gapped file transfer situations, and it is entirely a consequence of the protocol underneath.
How QRTP moves the data
QRTP is the protocol that turns a file into a stream of QR codes. The sender slices the payload into packets of 368 bytes (large) or 40 bytes (small), runs the bytes through Wirehair fountain coding, prefixes each block with a 4-byte block_id, and renders the result as QR frames at a configurable frame rate — so a scanned frame is a block, and lost frames are simply blocks that never arrived. The link is unidirectional: the sender cannot observe the receiver, so correctness comes from the code, not from acknowledgements. Rendered frames come in two layouts — full frames carry explicit stream headers and can address several streams (data on stream_id = 0, the network-metadata side stream on stream_id = 1), while squeezed frames imply stream_id = 0 and pack a 15-bit transfer_id whose high bit marks the frame as squeezed. When a network path does exist between the two devices, the sender puts the negotiation material on that metadata stream and the pair upgrades itself to a WebRTC/PeerJS peer connection, so the optical link is used when it is needed and the faster link is used when it is available.
The three ways to use it
| Mode | What it needs | What it can send |
|---|---|---|
| Browser sender (PWA) | A browser tab at qr-send.com, a screen large enough for the QR grid | File send, Safe Send, live camera/mic, multi-file and folder transfers |
| Terminal sender (CLI) | The native or WASI qrsend binary and a terminal; - reads from stdin | File send, piped data, multi-file transfers |
| Receiver | A camera and the receive page; no install on the scanning device | Rebuilds whatever the sender streams, including live media playback |
Browser sender
The web app is a progressive web app: pick a file, pick the transfer type, and the page renders the QR stream directly into the tab, with the frame rate and grid density under your control. Live media is captured by MediaRecorder and pushed through the same pipeline, which is why a phone camera can watch a webcam feed arrive as a QR stream.
Terminal sender
The standalone binary is the same protocol without a browser. It renders frames as terminal cells, so --cols and --rows define the QR grid, --fps defines the frame rate, and --invert, --fg and --bg handle contrast on real screens and real lighting:
15 frames per second, two QR codes per frame
The defaults are 15 frames per second and two QR codes per frame; the flags below make that explicit, and the grid is yours to change.
# 15 frames per second, two QR codes per frame
./qrsend --fps 15 --cols 2 --rows 1 file.pdf
Read from a pipe and write a manifest only
# read from a pipe, write a manifest only
cat archive.tar | ./qrsend --manifest-only -
Other flags cover error correction (--ecc), density (--packets-per-qr, --qrs-per-frame), labels (--stream-id, --label), repeat behaviour (--loops, --once), verbose and interactive runs, and an auditable JSONL trail via --log-audit. The same code compiles for macOS, Linux and Windows and as a WASI module.
Receiver on any phone camera
Receiving needs no software install and no account: point the phone or laptop camera at the sending screen and the receive page does the rest, scanning frames through a worker pool and feeding recovered packets into the decoder until the file is complete. Because the coding is fountain-based, the receiver can join late, miss frames, and still finish.
What QR Send deliberately does not do
QR Send does not store anything. There is no cloud storage, no server-side copy of your file, no account to create and no upload step, so there is nothing left to delete afterwards and nothing to leak from a third party. It also does not assume infrastructure: no Wi-Fi, no hotspot and no cable is required for the optical path, and the sender never needs a return channel from the receiver. Finally, it is not a platform-specific proximity feature — for how it lines up against one, see QR Send vs AirDrop.
FAQ
What is QR Send in one sentence?
QR Send is a tool that sends files and live media between two devices by streaming fountain-coded QR codes from one screen to a camera on the other, with no network, no account and no upload.
Do I need to install anything to receive a file?
No. The receiver is a web page: open it, grant camera access, and point the lens at the sending screen. Only the sending side needs the PWA or the qrsend binary.
Does QR Send upload my files anywhere?
No. The bytes are encoded into QR frames on the sending device and decoded on the receiving device; there is no cloud storage and no intermediate server holding your data.
Can I send a whole folder instead of one file?
Yes. Multi-file and folder transfers are packed into an archive automatically and streamed as a single transfer, which the receiver unpacks into the recovered file.
Does it still work with no network at all?
Yes — that is the point of the optical path. QRTP is designed for a one-way visual link, so two machines with no shared network, and no Wi-Fi in range, can still complete a transfer as long as one screen faces one camera.
Related reading
- What is the QRTP protocol? — QRTP is the QR Transport Protocol: a framing format plus fountain coding that turns a one-way camera link into reliable file transfer.
- How to transfer files to and from air-gapped machines — Step-by-step: move a file into or out of a machine that has no network, using a camera and a stream of QR codes.
- QR Send vs AirDrop — AirDrop is excellent inside Apple's ecosystem. QR Send transfers across whatever two devices are in the room, with no shared network.