Send Files Between Your Phone and PC Without a Cable

USB cables work, but only if you have the right cable on hand and your OS cooperates with file transfer mode. Emailing a file to yourself or messaging it through a chat app works, but it round-trips through a third-party server and often re-compresses images or video in the process. None of these are broken exactly — they're just workarounds for the absence of a direct pairing mechanism between two devices you already own.

Open /create-session on one device — say, your laptop — and it generates a session ID along with a QR code. On your phone, open /join-session and either scan the QR code or type in the session ID. Once paired, the two devices negotiate a WebRTC data channel and files stream directly between them, encrypted end to end by WebRTC's DTLS (or sealed with AES-256-GCM when a network forces them through the relay).

Because this runs over the internet rather than requiring both devices on the same local Wi-Fi network, it works even if your phone is on mobile data and your laptop is on a completely different connection — useful if you're not on the same router, or your phone is tethered rather than on Wi-Fi.

This also means it works across long distances, not just across a room: sending a file from a phone on one continent to a laptop on another works the same way it does across a kitchen table, since nothing about the session model depends on physical proximity.

Because both sides only need a browser, the operating systems never have to understand each other. The usual cross-platform headaches (AirDrop that only works between Apple devices, Quick Share (formerly Nearby Share) that only reaches Android and Windows, network shares that need the same workgroup and SMB settings) do not apply. The same steps work for Windows to Mac, Mac to Windows, Android to iPhone, iPhone to a Linux laptop or a Chromebook to anything.

• Windows and Mac: open the session in Chrome, Edge, Firefox or Safari on each machine. In Chromium-based browsers a large file is written straight into the Downloads folder while it arrives.
• Android and iPhone: scan the QR code with the phone's camera to join. Receiving on an iPhone or iPad works differently: iOS browsers cannot stream a download to disk, so the file is held in the browser's private storage until it is complete and then saved. Very large files are better received on a computer.
• Computer to computer on the same desk: when both devices are on the same network, the direct connection usually stays on that network, so speed depends on your Wi-Fi or Ethernet rather than your internet upload.

The mechanics behind this, and what happens when two networks will not let the devices connect directly, are explained in how P2P file transfer works.

If you find yourself moving files between the same two machines often — say, a build server and your phone for quick checks — the CLI's srift quick-share <file> command prints a https://srift.app/d/<token> link (add --qr to show it as a QR code) that you open on the other device, without redoing the pairing flow each time. The file streams from the sending machine when the link is opened and nothing is stored on a server, so keep the CLI running until the download finishes.

Getting a batch of camera-roll photos off a phone and onto a computer for editing is one of the most common reasons people reach for a cable in the first place — a browser session handles this without needing to find the right cable or wait for a photos app to sync. Grabbing a PDF or a form you filled out on your phone and getting it onto your work laptop for printing is another: no messaging yourself an attachment required.

It also works in the other direction — sending a document from your computer to your phone so you have it on hand while traveling, without needing cloud sync services like iCloud or Google Photos to be configured and signed in on both ends.

Some very restrictive networks (locked-down corporate Wi-Fi, certain hotel or airport captive portals) block the UDP traffic WebRTC prefers for a direct connection. SRIFT falls back to a WebSocket relay in that case, which is more tolerant of restrictive networks, though it means the encrypted file passes through a relay server instead of going device-to-device directly.

Battery and screen-lock behavior on mobile devices can also interrupt a transfer — some phones aggressively suspend background browser tabs to save power. Keeping the browser tab in the foreground on the phone side for the duration of the transfer avoids this on most Android and iOS versions.

On iPhone, iPad and Firefox for Android the file is first kept in the browser's private storage and saved to your files when it is complete, so the phone needs free space for it; other Android and desktop browsers write it into Downloads as it arrives.

One more honest caveat: browser-based transfer depends on both devices actually having a modern, up-to-date browser. Very old Android WebView-based apps or outdated browser versions can have inconsistent WebRTC support, which is worth keeping in mind if a transfer that normally works suddenly fails on one specific device.