Large File Transfer

Send Large Files Free, With No Signup

Most 'free' large-file services cap you at a couple of gigabytes, force an account past that, or make the recipient wait for a slow upload to finish before the download can even start. Srift skips the upload step and streams the file directly.

Why sending a large file usually turns into a problem

Email attachments are typically capped around 25MB by most providers, which rules out video, disk images, and most archives. WeTransfer's free tier tops out at 2GB and expires shared links after a fixed number of days. Google Drive and Dropbox will happily hold a large file, but only after you create an account, and the transfer counts against your storage quota whether you keep the file or not.

All of these services also share the same structural bottleneck: the file has to be uploaded to a server first, then downloaded from that server by the recipient. That's two full transits of the data instead of one, and if your upload connection is slow, the recipient is stuck waiting for a server-side copy to finish before they can start pulling their own copy.

How Srift moves large files without a size cap

When both people are online at the same time, one person opens /create-session and the other opens /join-sessionwith the session ID or QR code. Once connected, the browsers negotiate a direct WebRTC data channel and the file streams from sender to receiver in encrypted chunks. There's no server-side storage limit here because the file is never stored on Srift's infrastructure at all — it's only ever in flight, encrypted with AES-256-GCM before it leaves the sender's device.

If a direct WebRTC path can't be negotiated — symmetric NAT, a locked-down corporate firewall, or a network that blocks UDP — Srift automatically falls back to WebTorrent-style chunked transfer or a WebSocket relay. In relay mode for browser sessions, keys are derived on each device from the session ID, so the relay forwards ciphertext rather than readable file content.

Public quick-share links work differently, and it's worth being precise about it. A /d/<token> link is designed to be opened by any browser, curl or wget — clients that hold no key and run no Srift code. End-to-end encryption is therefore impossible on that path by definition: the file is streamed from the sender through Srift to the downloader in readable form. What Srift does guarantee for quick-share is no retention— bytes are relayed straight from the sender's disk to the open HTTP response, never written to Srift storage, and served with Cache-Control: no-store. If you need the server to be unable to read the content, use a session-based transfer instead of a public link.

For files you can't babysit in a browser tab

If you don't want to keep a browser tab open until someone downloads, the CLI has a dedicated command: srift quick-share /path/to/file. It prints a public download link in the form https://srift.app/d/<token> that the recipient can open in any browser or fetch with curl -OJ. You can add --once for a single-use link, --ttl 2h to auto-expire it, or --max-downloads 5 to cap how many times it can be pulled.

What this does and doesn't solve

Being honest about the trade-offs: a live browser-to-browser session needs both people online at the same time. If you need a "grab it whenever you're free" link, use quick-share instead of the live session flow — but that link only stays alive while the sending device and its CLI process keep running. Close the terminal or shut down the machine, and the link stops resolving.

Removing the artificial size cap doesn't change physics: a 50GB file still takes as long as your upload bandwidth allows. Srift removes the server-imposed limit and the double-transit overhead, it doesn't make your internet connection faster.

Srift vs. WeTransfer, Drive, and email attachments

  • Email attachments: hard cap around 25MB, no encryption beyond transport, requires an inbox on both ends.
  • WeTransfer (free): 2GB cap, links expire after a fixed window, uploads before recipients can download anything.
  • Google Drive / Dropbox: no hard cap, but requires an account, counts against storage quota, and the file lives on a third-party server indefinitely unless you delete it.
  • Srift: no account, no service-imposed size cap, direct P2P or ciphertext-only relay, and the file isn't retained in cloud storage after the transfer.

See the full breakdown on the WeTransfer alternativepage if you're specifically weighing Srift against WeTransfer's free and paid tiers.

Frequently asked questions

Related guides

Try it yourself — no account required

Open Srift in your browser or run the CLI. There's nothing to install to receive a file, and nothing to sign up for to send one.