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 Free allows up to 3 GB per transfer, 10 transfers or 3 GB per 30 days, and links that expire within 3 days (per its plan limits page, checked October 2026). Google Drive and Dropbox will hold a large file, but only after you create an account, and the file counts against your storage quota until you delete it.
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-session with 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 is only ever in flight, protected by WebRTC's DTLS encryption between the two browsers.
If a direct WebRTC path can't be negotiated — symmetric NAT, a locked-down corporate firewall, or a network that blocks UDP — SRIFT switches to a WebSocket relay within a few seconds. Each chunk is encrypted with AES-256-GCM on the sending device before it reaches the relay, under a fresh key the two devices agree on for that transfer, so the relay forwards ciphertext rather than readable file content.
On the receiving side the browser writes the file straight into its own download: it shows up in the Downloads folder while it is still arriving, like any internet download, so a large file does not have to fit in memory. In our tests a 20 GB browser-to-browser transfer used about 100 MB of page memory. Firefox, Safari, iPhone and iPad browsers first keep the file in the browser's private storage and save it to Downloads when it is complete, which needs the space twice for a moment.
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. The file streams straight from the sender's disk through the SRIFT relay and is never written to SRIFT storage. Add --encrypt and the link is end-to-end encrypted: the file is encrypted on the sender's device and the key travels in the part of the link after #, which browsers and HTTP clients never send to a server. Opening the link in a browser decrypts it locally; srift get decrypts it in a terminal. Without encryption a link is protected by TLS in transit only.
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 -fLOJ. 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. The link is served from your machine, so the CLI keeps it alive in the background; on a server or CI job, add --wait to block until the file has been downloaded. For large files, recipients can use srift get <url>, which resumes interrupted downloads.
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.
Reloading the receiving page continues the same download. A receiving tab that stays closed for more than about a minute ends it, and the file has to be sent again. If a direct connection drops mid-file, the transfer continues over the encrypted relay from the bytes already received.
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): 3 GB per transfer and 10 transfers or 3 GB per 30 days, links expire within 3 days, and the upload must finish before anyone can download.
- Google Drive / Dropbox: high per-file limits, but requires an account, counts against storage quota, and the file stays on a third-party server until you delete it.
- SRIFT: no account, no service-imposed size cap, direct P2P or an encrypted relay (quick-share links are E2EE with
--encrypt), and the file isn't retained in cloud storage after the transfer.
See the full breakdown on the WeTransfer alternative page if you're specifically weighing SRIFT against WeTransfer's free and paid tiers.
Frequently asked questions
Related guides
WeTransfer alternative
How SRIFT compares to WeTransfer's free and paid tiers.
Peer-to-peer file transfer
The WebRTC and encrypted relay architecture under the hood.
Encrypted file sharing
What AES-256-GCM end-to-end encryption actually protects.
Share files without uploading
Skip the cloud upload step entirely.
Go deeper
More in P2P File Transfer.
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.