ByteScope

QR File Transfer

Beam a file from one screen to another camera — no network, no cable, no pairing, no account. Just light.

The file is split, encoded and displayed entirely in your browser — nothing is uploaded.

Send a file

Pick a file, then point the other device's camera at the animated code. The stream loops forever, so a missed frame costs nothing.

Drop a file here

or click to browse — up to 5 MB

Frame rate

Higher is faster, but a camera that cannot keep up will read fewer frames.

QR density

Smaller codes scan more reliably; bigger codes move more data per frame.

Browser Support Matrix

Sending is only a canvas, so it works everywhere. Receiving depends on the camera and on how fast this browser can decode QR codes.

FeatureChromeEdgeFirefoxSafari
Sending (canvas QR animation)SupportedSupportedSupportedSupported
Camera access (getUserMedia)Needs a secure context (HTTPS) and your permission.SupportedSupportedSupportedSupported
BarcodeDetector (fast scan)Chromium only, and not guaranteed even there: Linux Chromium builds frequently ship without it, so this page probes both the constructor and the QR format at runtime rather than trusting the browser name.Partial supportPartial supportNot supportedNot supported
Fallback scan (jsQR)Works in every browser, but reads fewer frames per second.SupportedSupportedSupportedSupported
Fullscreen senderiOS Safari restricts programmatic fullscreen to video elements.SupportedSupportedSupportedPartial support

Detected browser capabilities

  • BarcodeDetector …
  • QR format supported …
  • mediaDevices …
  • Secure Context (HTTPS) …

About this tool

Pick a file on the sending device and this page splits it into blocks, encodes them with a Luby Transform fountain code, and plays them as an endless stream of QR codes at 5 to 20 frames per second. On the receiving device, open the same page, point the camera at the first screen, and watch the progress bar fill as frames are decoded; the moment enough blocks have arrived, the file is reassembled, verified against a CRC-32 checksum, and offered as a download. The only thing crossing the gap is light — no network, no server, no pairing, no cable, no account — which also means the two ends can be any pair of operating systems that can show a web page.

Why a missed frame costs nothing

The channel is strictly one-way: the receiver has no way to say "resend frame 37". A fountain code is built for exactly this. Instead of sending block 1, block 2, block 3 in order, every QR frame carries a random mixture of blocks, and any sufficiently large subset of frames reconstructs the whole file — so when the camera blinks, the phone shakes or autofocus hunts for a moment, nothing is lost; the next frames carry the same information in fresh combinations. Drop 40% of frames and the transfer still finishes, just a little later. It is also why the sender simply loops forever: it cannot know what the receiver has caught, and with a fountain code it does not need to.

Honest numbers — what this channel is and isn't for

This is a narrow channel: a few kilobytes to a few tens of kilobytes per second, limited by the camera shutter and the screen's refresh rate. That's perfect for text — a config file, an SSH key, a certificate, a wallet seed, a small document, up to a few megabytes — and hopeless for photo libraries or video. The sweet spot is two devices in the same room that can't reach each other any other way: no shared Wi-Fi, a locked-down corporate laptop where you can't install anything, an air-gapped machine, two operating systems that refuse to talk. Sending works in every browser (it's just a canvas drawing QR codes); receiving is fastest where the BarcodeDetector API exists — Chrome, Edge, Opera, and Chrome on Android — and falls back to a slower JavaScript decoder elsewhere. One deliberate boundary: there's a transfer size cap and no batch or automation mode, because an unattended, unbounded screen-to-camera channel is an exfiltration path out of an air-gapped machine, and we're not going to build a polished tool for that.

Frequently asked questions

How big a file can it actually move, and how long does it take?

Plan around a few kilobytes to a few tens of kilobytes per second — the ceiling is set by how fast a camera can cleanly capture a changing screen, not by the code. A 40 KB config file takes seconds; a few hundred kilobytes of certificates, a minute or two; a few megabytes is the practical upper end, and the tool enforces a hard size cap. For anything bigger — photos, video, archives — this is the wrong tool, and we'd rather say so than let you watch a progress bar for an hour.

The receiver already finished — why is the sender still playing QR codes?

Because the sender genuinely cannot know. The channel is one-way — light goes from screen to camera, and nothing comes back — so the sending page just keeps looping fountain-coded frames until you stop it. That's not a bug; it's the exact design that makes the whole thing work without pairing. Once the receiver shows the completed download, stop the sender whenever you like.

Is my file uploaded anywhere?

No — and not in the usual "we promise the server deletes it" sense: there is no server in the path at all. The file is read, split and encoded in the sender's browser, travels as light, and is reassembled in the receiver's browser. You can confirm it in the DevTools Network tab on both ends. The file and its name never leave the device; the only thing the site's analytics record is that a transfer happened, along with a coarse size bucket.

Why won't the receiving side work in my browser?

The camera side decodes fastest with the BarcodeDetector API, which is Chromium-only: Chrome, Edge and Opera on desktop, plus Chrome on Android. Where it's missing — Firefox and Safari — the page falls back to a JavaScript QR decoder, which works but reads fewer frames per second, so transfers take longer. You'll also need to grant camera permission when asked. The sending side has no such requirement: drawing QR codes on a canvas works in every browser.

Is this secure? Couldn't someone else's camera read the codes too?

Yes, it could — and you should hear that plainly: anyone who can see the screen can capture the file. The QR frames are not encrypted; the privacy of this channel is the physical privacy of the room you're in. If the file matters — a key, a seed, credentials — encrypt it before sending (an age file, a password-protected 7z, a GPG blob) and move the passphrase some other way. Relatedly, the size cap and the absence of any batch or automation mode are deliberate: a polished unattended screen-to-camera channel would be an exfiltration tool for air-gapped machines, and we won't build one.