QR Send vs WeTransfer and cloud sharing

Direct answer

Cloud sharing uploads your file to a provider's server, keeps a copy for as long as its retention policy allows, and sends the recipient a link. QR Send has no server and no storage: bytes travel from the sender's screen, through the camera, into the receiver's browser, so sending and arriving are the same moment. Both people must be present.

Key takeaways

QR Send moves data over a unidirectional optical link: the sender renders QRTP frames, the receiver's camera decodes them, and no server sits in the path.
Cloud sharing's trade-off is a stored copy: the provider holds the file until its retention policy deletes it, and anyone with the link can fetch it first.
Large QRTP packets are 368 bytes and small ones 40 bytes — a 4-byte block_id prefix plus packet_size − 4 payload bytes, up to 64,000 blocks per transfer; full frames carry explicit stream headers while squeezed frames imply stream_id = 0.
The optical link is the fallback, not the ceiling: QR Send negotiates a WebRTC/PeerJS peer connection over stream_id = 1 metadata, but never uploads the file.

Where the file lives

Cloud sharing: a copy on the provider's disk

A cloud service takes your bytes, writes them to storage it controls, and hands you a link. The upload is asynchronous: the recipient can be asleep or in another city, and the file is still there later — a genuine capability, and why the model won. The cost is that the file now lives somewhere you do not own: its lifetime is the provider's retention policy, its access control is the link, and deletion happens on the provider's schedule and in the provider's logs.

QR Send: the same bytes on two devices, and nowhere else

QRTP streams the file as fountain-coded packets rendered into QR frames. The sender's screen is the transmitter, the receiver's camera is the wire, and reconstruction happens in the receiver's browser. Sending and arriving are one event, not two separated by a queue, so both people must be in the same room with line of sight between a screen and a camera.

The framing is deliberately small so a handset camera can read it:

large packet (368 B):  [ block_id 4 B ][ Wirehair payload 364 B ]
small packet  (40 B):  [ block_id 4 B ][ Wirehair payload  36 B ]

Fountain coding is what makes a camera-readable stream survivable: frames can be missed or half-occluded, and the receiver needs enough distinct blocks rather than specific ones. A payload that fits in one packet skips the fountain and is sent in direct mode. For the wider picture, start with QR Send.

Side-by-side comparison

Question	Cloud sharing (WeTransfer, Drive, Dropbox-style)	QR Send
Where the file lives	On provider-operated storage, written by an upload	In memory on the two devices; no server copy
Account needed	Usually one to send, often one to receive, depending on provider and link settings	None; browser PWA on both ends, or the `qrsend` CLI
Both parties present	No — asynchronous: upload now, download later	Yes — a live optical link; sending and arriving are one moment
Size limits	Set by your plan and the provider's per-transfer ceiling	No server quota; the bounds are 64,000 fountain blocks and how long both people stay put
Speed	Your uplink and the provider's capacity; usually the fastest option over the internet	Frame rate and QR density: one 368-byte packet per frame at `--fps 15` is 5,520 B/s before fountain overhead, and `--packets-per-qr` multiplies it
Retention	Until the provider's policy or your account removes it; free tiers typically expire transfers	Nothing retained; there is no stored copy, and closing the receiver ends it
How a third party could obtain it	Provider-side access or a legal request, anyone holding the link, a compromised account	A camera with line of sight to the screen for the duration, or a seat on the peer connection; no stored copy to subpoena

The network path, and why nothing is uploaded

QR Send is not a no-network tool; it is a no-server tool. The optical channel carries two logical streams: data on stream_id = 0 and network metadata on stream_id = 1. When a peer connection is possible, the sender puts its network metadata into stream_id = 1, the receiver reads it off the screen, and the ends negotiate a WebRTC/PeerJS session, so throughput becomes network-bound instead of frame-rate-bound. If nothing can be negotiated the transfer continues optically: the upgrade is an optimisation, not a dependency, and there is never an upload step.

./qrsend --fps 15 --cols 2 --rows 1 --packets-per-qr 1 --label "contract.pdf" contract.pdf

cat contract.pdf | ./qrsend --fps 15 --cols 1 --rows 1 -

--cols, --rows, --fps, --ecc, --packets-per-qr and --qrs-per-frame trade screen area and legibility against throughput; --invert, --fg and --bg matter on dark terminals.

When cloud sharing is the right tool

For most documents, most of the time, a cloud service is the better tool, and it is worth saying so. Choose it when the recipient is in another city or offline when you send; when you need a durable record of delivery; when the file is too large to carry screen-to-camera in one sitting; when the link must still work next week; or when your organisation already has a data-processing agreement covering that storage. Presence is a cost, and asynchronous delivery is worth paying when presence is inconvenient. Ecosystem lock is separate; see QR Send vs AirDrop.

Reach for the optical path when the file must exist nowhere but the two machines: air-gapped or clinical devices, documents covered by a rule forbidding third-party storage, field sites with unreliable connectivity, or a handoff where accounts and share permissions cost more time than the transfer. In a fixed setting such as a front desk or lobby display, presence becomes an advantage — see one screen, many receivers.

What to tell your compliance team

Describe it as a real-time, line-of-sight transfer rather than a storage service: no third-party processor, no data at rest to inventory, no retention schedule to configure, and no provider-held link outliving the meeting. The transfer runs as a unidirectional optical link, and any WebRTC peer connection is negotiated over that same link and stays peer-to-peer. That replaces the usual questions — where is it stored, who can access it, when is it deleted, will the provider sign an addendum — with questions about the room: is line of sight controlled, could a bystander's camera see the screen, and do you want payload encryption on top, since Safe Send adds AES. For your own records the CLI emits an audit log with --log-audit and machine-readable batches with --dump-batches-json or --manifest-only. If policy requires a provider you can point at with an agreement and a deletion SLA, cloud sharing is the right tool; say so.

FAQ

Does QR Send need internet?

Not for the transfer itself: the link is optical, screen to camera, and works fully offline. The network matters only when both ends can reach each other and a WebRTC peer connection can be negotiated to raise throughput.

Can I send to someone in another city?

Not optically — both devices must be in the same room, because the sender's screen is the transmitter. If the two ends can reach each other over the network the peer connection covers it, but a cloud service is usually simpler by then.

Is QR Send faster than uploading to a cloud service?

Usually not. Cloud uploads are bounded by your uplink and the provider's capacity; the optical fallback is bounded by frame rate and QR density, such as 368-byte packets at --fps 15. The WebRTC upgrade is what makes QR Send competitive.

Does the recipient need an account?

No. The receiver is a browser page using the camera, and the sender is either the same browser app or the qrsend binary. Nothing is registered and no link is left to forward.

What stops someone else from reading my transfer?

Line of sight. Reconstructing the file takes a camera aimed at the sending screen for essentially the whole transfer, so control of the room is the access control. If the room is not controlled, use Safe Send so the payload is encrypted on top of that.