2026-08-14

Should you encrypt a file before sending it through WeTransfer or another file-transfer service?

Sending a large file — a video edit, a batch of RAW photos, a folder of design comps, a signed contract too big for email — through a free transfer link like WeTransfer is routine enough that most people never think about what they've agreed to by clicking send. In July 2025, a routine terms-of-service update made that worth thinking about, not because of a hack, but because of what the fine print itself said.

What WeTransfer's terms actually said, for about two weeks

Sometime after July 2, 2025, WeTransfer quietly updated clause 6.3 of its terms and conditions. The version still live on July 14, as captured by the Wayback Machine, read: users "hereby grant [WeTransfer] a perpetual, worldwide, non-exclusive, royalty-free, transferable, sub-licensable license to use your Content for the purposes of operating, developing, commercializing, and improving the Service or new technologies or services, including to improve performance of machine learning models that enhance our content moderation process." The same clause granted the right to "reproduce, distribute, modify, prepare derivative works based upon, broadcast, communicate to the public, publicly display, and perform Content" — with no compensation specified anywhere in it. For a service built around freelancers and studios sending unreleased creative work, client deliverables, and NDA-covered material, seeing "perpetual" and "commercializing" in the same sentence as "machine learning models" was enough to spread fast through creative communities online.

The walk-back, and what's still there afterward

On July 15 — one day after that wording was captured — WeTransfer revised clause 6.3. The new version drops "commercializing," "machine learning," and "derivative works" entirely, reading instead: "You hereby grant us a royalty-free license to use your Content for the purposes of operating, developing, and improving the Service." A WeTransfer spokesperson told the press the company does not "use machine learning or any form of AI to process content shared via WeTransfer, nor do we sell content or data to any third parties," and told the BBC the wording was changed "as we've seen this passage may have caused confusion for our customers." That's a real, fast correction — but worth reading precisely: the revised clause still grants WeTransfer a license to use uploaded content to operate and improve its service. What changed was the scope of that license, not whether one exists. Nothing about how the file itself is transmitted or stored changed at all.

Why this isn't really a WeTransfer story

The specific clause got walked back because enough people noticed and objected within about two weeks. The pattern it illustrates doesn't go away with that one correction: a free file-transfer service's terms are a document the company can amend, and a copy of whatever you upload sits on that company's servers governed by whichever version of that document is current when the file arrives there — not the version you skimmed the first time you used the tool. None of this requires a breach or a hacker. It only requires uploading the actual file and trusting that the terms you agreed to will still be the terms that apply to it.

What encrypting the file first actually changes

Encrypting a file locally before uploading it doesn't rewrite anyone's terms of service, and it doesn't stop a transfer service from technically holding whatever license its current clause grants over the bytes it receives. What it changes is what those bytes are. A license to "reproduce, distribute, modify, prepare derivative works based upon... and publicly display" a design file, a contract draft, or a set of client photos is a real exposure; the same license over an opaque, passphrase-locked ciphertext blob that no one but the intended recipient can open is not. The actual content — the thing anyone would want to reproduce, redistribute, or feed into a model — never reaches the transfer service in usable form at all. This doesn't cover everything a transfer service still sees, though: filenames, file sizes, sender and recipient email addresses, and timestamps stay visible unless the file itself is renamed before upload. It's a fix for the content of the file, not for the metadata around the transfer.

Where NearSeal fits

NearSeal encrypts a file entirely in the browser before it goes anywhere — the file and the passphrase never leave the device, and there's no account or upload involved in the encryption step itself, so the only thing that ever reaches a transfer service is whatever was chosen to send it. The default format derives an AES-256-GCM key from your passphrase via PBKDF2-SHA256 at 2²⁰ iterations; the optional age-encryption.org format uses scrypt and ChaCha20-Poly1305 instead and opens with the standard age or rage CLI, which matters specifically for this scenario — the client or collaborator on the other end of that WeTransfer link doesn't need an account on this site or any particular software to open what was sent, just the passphrase and any age-compatible tool. What NearSeal can't do is stop a transfer service from changing its terms again, or guarantee every recipient bothers to decrypt correctly. What it can do is make sure that whatever a file-sharing service's current terms of service say it's licensed to do with "Content," the content itself was never actually in its hands to begin with.