QR Data Transfer

QR Data Transfer sends a file from one device to another with nothing in common between them — no shared Wi-Fi, no cable, no cloud account, no app to install. One screen displays the file as an animated grid of QR codes; a second device's camera reads the whole grid at once and rebuilds the file. Everything happens in your browser on both ends — the file is never uploaded anywhere.

How to use it

On the sending device:

1. Switch to Send and choose a file (up to 32 MB).
2. The codes start animating automatically — hold the screen steady where the other device's camera can see it. Three sliders control the trade-off:
   • Codes at once is the main speed dial. The receiver decodes every code it can see in a single camera shot, so a 2×2 grid moves four times the data of a single code and 3×3 moves nine times. Each code gets a smaller slice of the screen as you turn it up, and past a point they become too fine for the camera to resolve.
   • Frame size is how much screen the grid occupies — turn it up to buy back the room a larger grid costs.
   • Speed is how often the grid refreshes. Above the receiving camera's own frame rate (usually about 30 per second) the extra refreshes are simply missed, so it's rarely worth pinning to the maximum.

On the receiving device:

1. Switch to Receive and tap Start camera.
2. Point the camera at the sending screen so the whole grid is inside the frame. A progress bar fills in as frames arrive — you can start at any point in the stream, not just the beginning.
3. Once enough frames have been received and the whole file's checksum verifies, the rebuilt file appears with a Download button.

The sender streams an endless run of QR frames, each one self-contained, so timing doesn't matter — start scanning whenever you're ready, and a missed frame (blur, a hand shake, a slow camera) just costs a moment, never a wait for a specific frame to loop back around. Sender and receiver never negotiate anything, so the grid setting is purely the sender's call: change it mid-transfer and the receiving device carries on without noticing.

Nothing is being received — what should I change?

Work down this list, one change at a time:

1. Turn Codes at once down (3×3 → 2×2 → 1×1). This is the usual culprit: it is the setting most likely to have pushed each code below what the receiving camera can resolve.
2. Turn Frame size up, and move the two devices closer together so the grid fills more of the camera's view.
3. Clean the camera lens and steady both devices. Autofocus hunting on a moving handheld phone costs more frames than any slider.
4. Turn Speed down if the sending device looks like it's struggling to keep up with its own animation.

Why this instead of AirDrop, a cable, or a shared drive?

Those all need something in common between the two devices — the same OS ecosystem, a physical port, or both being online at once. QR codes only need line of sight, which makes this useful for moving a Wi-Fi password, a TOTP/2FA secret, a config file, or a small document onto a device that has no network access at all — an offline machine, a guest's phone, a fresh device mid-setup.

What size files does it handle?

Up to 32 MB, though how long that takes depends entirely on how you set it up. The Send screen shows a live estimate before you start — check it before committing to a large transfer, and raise Codes at once and Frame size to bring it down. That estimate is a rough one either way: because each frame carries a random mix of the file's data rather than one fixed chunk, the receiver needs "enough distinct frames," not "every specific frame" — a missed or blurry read costs a little time, not a stall. Small text, JSON and config files are effectively instant; photos and small archives are comfortable; a file near the 32 MB cap is a genuine sit-down commitment however you set the sliders.

How does it get any speed out of QR codes?

A few things, all visible in the interface. The receiver uses a real WebAssembly barcode decoder (ZXing) that finds every QR code in a camera frame in one pass, rather than the single best one — which is why the sender can show a grid and have all of it read at once, and it does so across a small pool of decode workers in parallel rather than one at a time, so several camera captures can be mid-decode simultaneously. The sender's grid is rendered directly to a canvas rather than built up from separate images, and each code skips the (normally worthwhile) search for the best-looking QR mask pattern — a search built for a code printed once and scanned for years, not one shown on screen for a fraction of a second and never repeated — which is what keeps the animation itself smooth even at larger grid sizes. And the frames are fountain-coded: each code carries a random mix of the file's blocks rather than one fixed chunk, so the receiver only needs enough distinct codes, never any particular one, and nothing ever has to be re-sent or waited for.

Is it secure?

The file is encoded as plain (unencrypted) QR data — anyone with a camera pointed at the sending screen during the transfer can capture it, same as reading a note held up in the same room. Treat it like showing someone a physical piece of paper: fine for most files, but don't rely on it alone for something highly sensitive.

The receiver shows the wrong filename

The rebuilt file is downloaded as transfer.<ext> (the extension is guessed from the file's type) rather than its original name — data URLs don't carry filenames, so the original name isn't available to reconstruct. Rename it after downloading if that matters.

Need to read what's inside a QR code you already have as an image, rather than transfer a file? Use the QR Code Decoder. To generate a single static QR code for a link or text, see the QR Code Generator.