"Secure file transfer" describes at least four different promises, and most services keep only some of them. Before comparing anything, work out which of the four you actually need — a service can be excellent at one and useless at another, and the marketing word is identical in every case.
The four promises
1. Encrypted in transit. Nobody can read the file while it crosses the network. That is HTTPS. Every service in this category does it; a provider advertising it as a feature is padding.
2. Encrypted at rest. The file is encrypted while stored. Nearly universal too — but the question that matters is who holds the key, and that is rarely on the marketing page.
3. End-to-end encrypted. The service never holds the key and cannot read your file even if compelled to. A much stronger promise, and much rarer than the number of companies claiming it. What it really means, and how to check.
4. Access control. Who can reach the file, for how long, how many times, and whether you can take it back. This is the one that prevents most real incidents, and the least discussed.
Most people asking for "secure file transfer" want the fourth and assume they are asking for the third.
Which one you need
- A contract to a client: access control. Expiry, a password in case the email is forwarded, and the ability to revoke. The risk is not cryptography; it is the link sitting in an inbox for three years.
- Health, legal or special-category personal data: access control, plus a data processing agreement, plus clarity on jurisdiction. Sending sensitive client data covers the obligations.
- Something where the service itself is part of your threat model: genuine end-to-end encryption — and scepticism, because the claim is cheap to make.
- A video to a colleague: none of this. Use whatever is convenient.
How to check the claim rather than believe it
Three questions separate real end-to-end encryption from the marketing version:
- Can the service show a preview of my file? If yes, it decrypted it, so it holds the key. The fastest test there is, and decisive.
- Can it scan for viruses? Same logic.
- If I lose my password, can it recover my files? If yes, it holds the key. Real end-to-end encryption means losing the key loses the file — that is the price of the property. A provider offering both recovery and end-to-end is claiming two things that do not fit together.
That last one is the honest test, and worth applying to anything sold as zero-knowledge.
Where services stand
From each company's own documentation, on the dates given; no competitor prices here.
Most mainstream transfer services — WeTransfer (checked 31 July 2026), Dropbox Transfer (21 September 2026), Filemail, Smash and SwissTransfer — sit in the "encrypted in transit and at rest, provider holds the keys" category. That is a normal, reasonable design: it is what makes previews and virus scanning possible, and for most work it is the right trade.
Where they differ is access control, so compare that directly: password protection, expiry you set, download limits, and whether you can revoke a link after sending. Ask about revocation specifically — it is the control people most often assume exists. Password links, for instance, are a paid feature on Dropbox Transfer and on Filemail's Pro plan (checked 21 September 2026).
Yungle, which I build, is in the same category by default, and I say so plainly: every file is always encrypted with its own key, and the service holds those keys — which is how previews and virus scanning work. For the cases where the service should be part of your threat model, there is an opt-in end-to-end mode, free, where the browser seals the file and the key travels in the part of the link after the #, which never reaches the server. Access controls are passwords, expiry dates, download limits and revoking a link. Servers are in Germany, and the data processing agreement is published.
Availability is a security property too, and on that axis a large provider beats a small one — worth weighing if "reachable on a deadline" is part of what you mean by secure.
The controls that prevent actual incidents
Leaks in this category happen for boring reasons, not cryptographic ones:
- A link forwarded to the wrong person — fixed by expiry and revocation, not encryption.
- A link that still works two years later — fixed by retention you actually set. How long should you keep client files?
- The wrong folder shared — fixed by handing over a copy rather than lending access to your storage.
- The password in the same email as the link — fixed by sending it another way, which costs nothing and is skipped constantly.
Do those four on an ordinary service and you are ahead of most people using a "secure" one badly. The step-by-step version is how to send large files securely, and the security page says exactly what Yungle does and does not do.
Choosing
Name which of the four promises you need. Check that claim with the preview and password-recovery tests. Compare access controls. Compare jurisdiction if the data concerns other people. Compare transfer size last — it is the number every page leads with and the one least likely to matter to a decision about security.