ByteScope

Device Transfer

Files and whole folders straight from one device to another, over a link the two of them make between themselves.

Files travel straight between the two devices. The pairing server only ever relays connection information — it never sees a byte of what you send.

Which end is this device?

Pick a side, pair the two devices, then send. Both ends need this page open at the same time.

This device reads the files and pushes them across the link.

What works where

Measured claims only. Anything we have not run ourselves is marked untested rather than guessed.

FeatureDesktopAndroidiOS
Pair and connectNeeds WebRTC and a secure context.worksnot testednot tested
Send a whole folderDesktop Chromium walks a real folder; Android falls back to the basic picker; iOS Safari offers files, not folders.workspartly worksdoes not work
Rebuild the folder on diskNeeds the File System Access directory picker — desktop Chromium only.partly worksdoes not workdoes not work
Receive as a zipThe fallback everywhere else: staged in private storage, then downloaded.worksnot testednot tested
Keep the screen awakeScreen Wake Lock. Where it is missing, a sleeping device pauses the transfer.worksnot testednot tested
Relay across the internetDeliberately not built. Without a relay the two devices need a route to each other, normally the same Wi-Fi.not applicablenot applicablenot applicable

The folder-level experience is desktop-to-desktop and Android. iOS receives better than it sends.

This browser

  • WebRTC …
  • Folder picker …
  • Private storage …
  • Wake lock …
  • Secure context …

About this tool

Open this page on both devices, show a 6-digit code on one and enter or scan it on the other, and the two browsers negotiate a direct connection to each other. Then drop in files — or a whole folder, with its structure intact — and the bytes flow from one device to the other and nowhere else. There is no account, no app to install, no size limit imposed by an upload form, and no waiting for a file to climb to a server before it can come back down. On a shared Wi-Fi network the link runs at whatever the network can do, which in practice is tens of megabytes per second.

The server only ever relays connection information, never your files

This is the sentence worth reading twice, because it is the whole point. Two browsers cannot find each other on their own, so a small pairing service passes each side the other's connection details — network addresses and the parameters of the encrypted channel. That is all it ever handles. Once the two devices have a path to each other the pairing service drops out, and every byte of every file travels directly between them over an encrypted WebRTC data channel. Nothing is stored, nothing is logged, and there is nothing on any server to leak, because the files were never there. You can confirm it: watch the Network tab on either device while a transfer runs.

Folders, checksums, and what happens when the link drops

A folder is sent as a manifest first — every path, every size — and then file by file, so both ends know what to expect and the progress bar means something. Each file is hashed with SHA-256 as it is read and again as it is written, and the receiving side only keeps a file whose two digests agree; anything that fails is discarded rather than saved as a plausible-looking wrong file. If the link drops halfway through a large folder, reconnecting picks up where it stopped: the receiver states exactly how much of each file it has already written and verified, the sender skips those, and only the missing bytes cross the link. Paths are never quietly rewritten either — a name the receiving system could not store is refused by name rather than silently changed into something else.

Honest limits

The folder-level experience is best desktop-to-desktop and on Android; iOS receives better than it sends, because Safari will hand a page files but not a folder. Rebuilding a real directory tree on the receiving side needs the File System Access API, so that half is desktop Chromium; everywhere else the files are staged in the browser's private storage and handed over as a single zip at the end, split into parts when a transfer outgrows what the ZIP format can address. And there is deliberately no relay server: if the two devices have no route to each other — different networks, a carrier-grade NAT in the way — this page will tell you to put both on the same Wi-Fi rather than quietly pushing your files through a machine we own.

Frequently asked questions

Do my files pass through your server?

No. The only thing the server handles is connection information — the addresses and channel parameters the two browsers need in order to find each other. Once they have, it steps out of the way and every byte travels directly between your two devices over an encrypted channel. There is no upload, no copy sitting in a bucket, and nothing to delete afterwards. If you want to check rather than trust: open DevTools on either device and watch the Network tab while a large file moves — you will see the pairing exchange and then nothing at all.

How fast is it, and how big a folder can I send?

On the same Wi-Fi expect tens of megabytes per second — fast enough that a few gigabytes of photos is a coffee, not an afternoon. Size is bounded by the receiving device's storage, not by us: files are streamed through in small pieces, so neither end ever holds the whole thing in memory. The practical ceilings are the receiver's free space and, when the files arrive as a zip rather than into a folder, the ZIP format's own limits, which the page handles by splitting the result into parts.

The transfer stopped halfway. Do I have to start over?

No — press reconnect. The receiving side keeps a per-file record of exactly how many bytes it has written to disk and verified, and that record is what the resume is built from, not a guess. The sender is told which files are already complete and skips them entirely, then restarts the interrupted file from the last point the receiver can prove it holds. Files still in flight when the link died are either resumed from a verified point or discarded and re-sent in full; a partial file whose checksum cannot be confirmed is never kept.

Why does it tell me to put both devices on the same Wi-Fi?

Because there is no relay server, and that is a deliberate choice rather than a missing feature. A relay would mean your files travelling through a machine we operate, which is exactly the property this page exists to avoid — and it would cost bandwidth we would then have to charge for. Two devices on the same network can almost always reach each other directly. Two devices on different networks sometimes can and sometimes cannot, depending on what each side's router does; when they cannot, the page says so plainly instead of pretending.

Which browsers and devices actually work?

Connecting works anywhere with WebRTC and a secure connection, which is every current desktop and mobile browser. Sending a whole folder is best on desktop Chromium, which can walk a real directory; Android falls back to a basic folder picker that reads everything up front; iOS Safari offers files rather than folders. On the receiving side, rebuilding the tree directly on disk needs desktop Chromium — everywhere else you get a zip download instead. The page reads your browser after it loads and shows you which of those you are in, rather than guessing from the user agent.

Related tools