A WeTransfer Alternative With No File-Size Limit

As of October 2026, WeTransfer Free allows up to 3 GB per transfer and up to 10 transfers (or 3 GB in total) in any rolling 30-day window, and free transfer links expire after a maximum of 3 days, according to WeTransfer's own plan limits page. Go past that and you need a paid plan. 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 an encrypted WebSocket relay that forwards 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: 3 GB per transfer, 10 transfers or 3 GB per 30 days. SRIFT: none enforced by the service.
• Account required: WeTransfer — email required to send. SRIFT — none.
• Link expiry: WeTransfer Free: at most 3 days. SRIFT: a quick-share link stays live while the sender's process runs, unless you set --ttl, --once or --max-downloads.
• Transfer path: WeTransfer: upload to its servers, then download from them. SRIFT: direct P2P when the network allows, otherwise a relay that forwards encrypted chunks without storing them.
• Ads / upsells: WeTransfer free — yes, on the download page. SRIFT — none.
• Encryption: WeTransfer: TLS in transit and encryption at rest with keys the provider manages. SRIFT: DTLS between browsers on direct transfers, AES-256-GCM with on-device keys on the relay and for --encrypt links; plain quick-share links are TLS-only in transit.
• 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 3 GB or monthly caps (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-share directly and get a link back programmatically — not something WeTransfer's consumer-facing upload form is designed for.