×

How It Works

1. The Sender

Select your Transfer Mode, choose the file you want to send, and press Start. Point your screen at the receiver's camera. Adjust the speed slider if the camera is struggling to keep up.

2. The Receiver

Click Receive and allow camera access. Point your camera at the QR codes on the sender's screen. The file will automatically download when all pieces are captured! The receiver doesn't choose a transfer mode — it automatically follows whatever mode the sender picked.

Transfer Modes (Sender Only)

The Transfer Mode choice only applies to the sender — it controls how the sender encodes and broadcasts the file. The receiver just watches and decodes whatever format shows up, so there's nothing to pick on that side.

📡 Fountain (2 Cameras) — Most Reliable: Broadcasts the same mixed-chunk fountain stream described below, at the exact same speed — but the sender can pause partway through and ask the receiver's camera exactly what's still missing, using the receiver's camera on the sender's screen, briefly reversed. On the sender, press "Pause & Request Status": it shows a status-request code for a couple seconds, then opens its own camera. On the receiver, that request is picked up automatically — it shows a small code listing what it's still missing, then a "Done" button to resume watching. Flip the sender's phone around to scan that code (it has about 15 seconds), then flip it back and press "Resume" to send just the missing pieces directly, instead of continuing to broadcast blind. This mode means the sender needs a working camera too, on top of the usual sending role — the app checks for that as soon as you select this mode and will tell you if it's not available. Using the pause adds real time (a 2-second request display plus up to 15-20 seconds for the handshake), so this isn't "faster" than plain Fountain — it's the same speed unless and until you choose to spend that extra time to finish a stalled or lossy transfer more reliably instead of continuing to gamble on blind broadcasting. If either side can't complete the handshake in time, the sender just resumes normal broadcasting — nothing is lost.

🚀 Fountain — Fast: Mathematically mixes the data. If you miss a frame, don't worry—just catch the next one! Finishes as soon as enough random frames are caught.

🔄 Sequential (Loop) — Simplest: Sends chunks 1 by 1 in order. If you miss one, wait for the loop to come back around. Simpler decoding for older devices.

The Dot Grid & Pending Packets

Each dot represents a piece of the file.

• ■ Green: Chunk successfully captured/solved.
• ■ Blue Ring: The frame your camera is currently looking at.
• ■ Gray: Still waiting for this chunk.

Pending Packets: In Fountain mode, the sender mixes multiple original chunks together into a single QR code. If the receiver catches a mixed packet but hasn't caught the *other* chunks that make it up, it can't decode it yet. The app holds these "Pending" packets in memory. Once the missing pieces arrive, it will automatically solve them!

Under the Hood

For the curious: here's what's actually happening to your file between the two devices.

1. Compression. Your file is gzip-compressed in the browser before anything else happens. Most files shrink here, which means fewer QR frames to send.

2. Chunking. The compressed data is sliced into fixed-size 800-byte chunks. A 40KB file becomes 50 chunks; a 400KB file becomes 500. The very first QR code isn't file data at all — it's a small JSON header telling the receiver the filename, original size, compressed size, chunk count, transfer mode, and a checksum (more on that below).

3. Base45 encoding. QR codes have a special "alphanumeric" mode that packs data more efficiently than raw bytes, but it only supports 45 specific characters (0-9, A-Z, and a handful of symbols). Raw file bytes obviously don't fit that alphabet, so each chunk is run through Base45 encoding first — a scheme that packs 2 bytes into 3 of those 45 characters. This is what lets the QR codes stay small and quick to display and scan, instead of falling back to QR's much less efficient byte mode.

4. Sequential mode. Each QR code carries one chunk's index and its Base45-encoded bytes, e.g. 17,ABC123.... The receiver just collects them by index and loops until it has every one. Simple, but if a single frame is missed, you're waiting for the sender to loop back around to it.

5. Fountain mode. Instead of sending chunks one at a time, the sender picks a small random set of chunks (1 to 4 of them, weighted toward fewer), XORs their bytes together, and sends the result along with the random "seed" that determined which chunks were picked. XOR is reversible: if you know the mixed result and all-but-one of the original chunks, you can recover the missing one by XOR-ing everything else back out. So the receiver doesn't need a specific frame — any packet that eventually lets it isolate an unknown chunk will do. As more chunks get solved, previously-unusable mixed packets often become solvable too, which is why progress can suddenly jump. This is a simplified version of what's called a "fountain code" or "LT code" — the same family of error-correction ideas used in things like distributed storage and some broadcast/streaming protocols, minus the more elaborate probability tuning those real-world versions use.

6. Checksum verification. Before compression, the sender calculates a CRC32 checksum of your original file and includes it in the header. Once the receiver has reassembled and decompressed every chunk, it calculates the same checksum on its own copy and compares. If they match, you know the file arrived byte-for-byte correct — not just "probably fine." If they don't match, you'll see a clear error instead of a silently corrupted download.

7. No network, ever. All of the above — compression, chunking, encoding, decoding, checksumming — happens entirely in your browser's memory using JavaScript. The only "transmission" is visual: light from one screen hitting another device's camera. Nothing is written to disk, uploaded, or logged anywhere in between.