Encrypted file transfer, explained without the marketing

The phrase "encrypted file transfer" covers products that do wildly different things. WeTransfer says encrypted. Google Drive says encrypted. Mega says encrypted. Tresorit says encrypted. Three of those four mean roughly what we mean: TLS while the file is moving, AES-256 while the file is parked. Mega and Tresorit mean something stronger, and this page spells out the difference.

sto.care is free, browser-only, has no signup, deletes every file after seven days, and lets you revoke the link earlier. Files travel over HTTPS and sit in AWS S3 encrypted with AES-256. That covers most threats people actually face. It is not end-to-end encrypted, and that distinction matters before you upload.

DefinitionsWhat "encrypted file transfer" actually means

There's a spectrum, and the marketing copy collapses it. Useful to spread it back out. Picture three layers:

The first layer is transport encryption. When your browser uploads a file, the bytes travel over TLS, the same protocol that puts the padlock in your address bar. Cloudflare's TLS explainer walks through what that does and doesn't protect against. Short version: a passive attacker on the network (a coffee-shop wifi sniffer, a transit ISP) can't read the bytes. TLS is the baseline. Any tool without it in 2026 should be skipped.

The second layer is encryption at rest. Once the file lands on the provider's storage, is it ciphertext on disk? Most modern providers say yes. AWS encrypts every S3 object with AES-256 by default in SSE-S3 mode. Google does the same in Drive. WeTransfer does the same in their bucket. The catch is that the keys live with the provider. The encryption protects against a physical disk theft from the data center. It does not protect against the provider itself, or against anyone with provider access.

The third layer is end-to-end encryption. The file is encrypted on the sender's device with a key the provider never sees, and only decrypted on the recipient's device. The EFF's Surveillance Self-Defense guide on encryption has the cleanest explanation. This is what changes the threat model: even if the provider is hacked, served a warrant, or just curious, they can't produce plaintext. Mega and Tresorit do this. We do not.

MechanicsHow sto.care actually encrypts files

When you upload a file, your browser opens a TLS 1.2+ connection to our API and to a pre-signed S3 URL. The file streams up encrypted in transit. At our edge, TLS terminates and the bytes flow into S3, which writes them to disk encrypted with AES-256 under the SSE-S3 scheme described in the AWS docs linked above. The DynamoDB metadata row stores the recipient email, an upload ID, and a TTL stamp seven days from creation.

On download, the recipient hits the link, our API checks the token, generates a short-lived signed S3 URL, and the recipient streams the file back over TLS. The file is decrypted by AWS at read time using the same SSE-S3 key. The recipient's browser sees plaintext. So does every layer in between, in theory. None of it leaves the EU until the recipient downloads it; the bucket is in eu-west-1 (Ireland).

Seven days after upload, an S3 object lifecycle rule sweeps the file out. The DynamoDB TTL purges the metadata in the same window. If you click the revoke link in your confirmation email before then, both happen immediately. After expiry, the download link returns a 404 and there's nothing to recover.

A few specifics worth pinning down. The TLS minimum is 1.2; cipher suites are whatever AWS API Gateway and CloudFront negotiate by default, which is the modern set. The S3 encryption is AES-256 server-side (SSE-S3, AWS-managed keys). We rate-limit uploads to ten per hour per IP, partly to keep abuse low, partly because the email confirmation step has a real cost. Executable file types (.exe, .sh, .bat, .ps1, .msi, .cmd, .com, .scr) are blocked at the upload step, both by extension and by MIME sniff. None of that is encryption strictly speaking, but it's how the system is hardened.

LimitsWhat sto.care does not do

The whole reason this page exists. Six things we don't do, that some competitors imply they do:

• Not end-to-end encrypted. Files pass through our infrastructure decrypted between TLS termination and S3 write. Anyone with sufficient access to our AWS account could, in principle, intercept that path.
• Not zero-knowledge. AWS holds the SSE-S3 keys, and we hold the AWS account. We could decrypt any stored file if we tried. We don't, but we could.
• No customer-managed keys. SSE-S3 uses keys AWS manages. We don't offer SSE-C or SSE-KMS with customer keys. You can't supply your own key per upload.
• No password protection per file. Whoever holds the download link can download until expiry or revoke. There's no second factor.
• No compliance certifications. Not HIPAA, not SOC 2, not FIPS 140-2, not ISO 27001. AWS underneath us holds many of these, but we don't inherit them in any meaningful contractual sense.
• No marketing-language claims about AES-256. Some sites describe AES-256 with adjectives lifted from defence procurement. We do not. AES-256 is AES-256 whether it sits on a phone or inside an NSA-approved standard.

Threat ModelWhen this is good enough

Most threats people actually worry about are the boring ones: somebody on the same wifi network sniffing the upload, the recipient's laptop being stolen with the file still in their downloads folder, the link sitting on a public Slack channel two years from now and getting indexed. TLS handles the first. We can't help with the second (nobody can, once the file is on someone else's machine). Auto-delete and on-demand revoke handle the third.

For everyday work, sto.care's threshold is genuinely fine. You're sending a 2 GB project file to a contractor. You're sending a contract to your accountant. You're sending a video to a friend. The risks worth caring about are network interception (covered) and the link living forever (covered). The threat of AWS being subpoenaed for your specific file is real but vanishingly low if you're not already a person of interest.

The plain framing is that "encrypted" in this tier of the market means "the obvious attacks don't work." A passive sniffer on hotel wifi gets nothing. A link forwarded to the wrong group chat dies in seven days, sooner if you click revoke. A forgotten file from a 2024 client engagement isn't still sitting indexed somewhere in 2026 because there's no archive to forget about. That's the floor, and the floor is high enough for the vast majority of files most people send.

ComparisonHow the major options stack up

Where each tool actually sits on the spectrum:

When To Look ElsewhereTools that genuinely beat us on encryption

If your threat model includes the provider itself, or you just want the strongest available cryptography, the following options handle that better than sto.care does.

Mega offers end-to-end encryption with keys derived from your password and held client-side. Their security page and published whitepaper describe the scheme (the AES key size depends on which part of their hierarchy you mean, so read the page rather than rely on a one-line summary). Free tier is generous (20 GB), and links can carry the decryption key in the URL fragment so recipients don't need an account. Worth knowing: Backendal, Haller, and Paterson at the ETH Zurich Applied Crypto Group published MEGA: Malleable Encryption Goes Awry in 2022, identifying five attacks against Mega's key hierarchy. Mega has since patched the issues the paper flagged.

Tresorit is the polished commercial option, Swiss-jurisdiction, end-to-end encrypted, with proper zero-knowledge architecture. It's paid (no useful free tier for transfer), and it's the one most legal and healthcare teams seem to settle on. If money isn't the constraint and the data is sensitive enough, this is the cleanest answer.

Proton Drive is Proton's end-to-end encrypted storage and sharing product. Free tier exists, integrates with Proton Mail, hosted in Switzerland. Slower to upload than the others in our testing, but the cryptography is solid and the company has a long privacy track record.

Signal isn't a file-transfer tool, but it does send files end-to-end encrypted between two installations of the app. For one-off sensitive transfers between two people who already trust each other, it's the simplest answer. Size cap is 100 MB per file though, so not for video.

FAQCommon questions

Other angles on the same product: temporary file sharing with auto-delete, file sharing without signup, or compare against WeTransfer and Google Drive.