A WeTransfer Alternative With No File-Size Limit

WeTransfer We Transfer Free limits you to 2GB per transfer and expires download links after a set number of days. Go past that and you're paying for WeTransfer Pro or Premium. The upload has to finish completely before the recipient can start downloading, because the file is sitting on WeTransfer's storage in between — your transfer speed is bounded by both your upload bandwidth and theirs.

None of this is a criticism of WeTransfer's engineering — it's just what a centralized upload-then-download model looks like at scale. Srift takes a structurally different approach for the cases where you don't need a hosted, permanent link and just want the file to get from A to B.

Open /create-session, share the session ID or QR code, and the other person joins from /join-session. Once connected, the browsers open a direct WebRTC data channel and the file streams straight across — no intermediate upload, no storage quota, no plan tier. If a direct connection can't be established (locked-down networks, symmetric NAT), Srift falls back to a WebTorrent-style chunked transfer or a WebSocket relay that only ever sees AES-256-GCM ciphertext, not the plaintext file.

For the "send now, they'll download later" case that WeTransfer is usually used for, the CLI's srift quick-share <file> command produces a https://srift.app/d/<token> link that works exactly like a WeTransfer download page — the recipient opens it in a browser and downloads directly, no Srift account needed on their end.

To be fair to WeTransfer: its hosted-link model means the file is available on WeTransfer's servers independent of whether your computer is on. Srift's quick-share link depends on the sending machine's CLI daemon staying reachable until the file is downloaded — if you shut the laptop, the link stops resolving. If you specifically need a link that survives your device going offline indefinitely, that's a genuine gap between the two models, and it's worth knowing before you pick one for a given use case.

• File size cap: WeTransfer free — 2GB. Srift — none enforced by the service.
• Account required: WeTransfer — email required to send. Srift — none.
• Link expiry: WeTransfer — fixed window (typically 7 days). Srift — persists until downloaded or the sender's process stops, unless you set --ttl yourself.
• Transfer path: WeTransfer — upload to server, then download from server. Srift — direct P2P by default, ciphertext-only relay as fallback.
• Ads / upsells: WeTransfer free — yes, on the download page. Srift — none.
• Encryption: WeTransfer — TLS in transit, provider holds decryption ability server-side. Srift — AES-256-GCM end-to-end, keys derived on-device.
• Bulk / repeat sending: WeTransfer — one link per transfer, re-upload each time. Srift — a single CLI daemon can mint multiple quick-share links from a script without re-uploading through a browser form.

If you occasionally send a small file to a client and WeTransfer's free tier has always been enough, there's no urgent reason to change anything. The switch matters most for three groups: people who regularly bump into the 2GB cap (video editors, photographers delivering RAW files, anyone sharing disk images), people who resent handing over an email address just to send a file, and developers or agents who want to script file delivery instead of clicking through a web form each time.

For that last group specifically, the CLI and MCP integrations mean a build pipeline or an AI coding agent can call srift quick-sharedirectly and get a link back programmatically — not something WeTransfer's consumer-facing upload form is designed for.