Encrypted File Transfer Explained in Plain Language
Published 2026-01-19 · Updated 2026-05-30 · 8 min read · By the SENDIT team
In transit, at rest, end-to-end: what each type of encryption actually protects, where the gaps are, and how to read a file transfer tool's security claims.
Almost every file sharing product on the internet says it is encrypted. Very few of them explain which encryption, protecting which stage, from whom. The word has become a trust badge rather than a description. This article breaks the term into the three stages that actually matter, explains what each one defends against, and gives you the questions to ask before you believe a claim.
Stage one: encryption in transit
Encryption in transit is what happens between your device and the server. It is TLS, the same technology behind the padlock in your browser bar. When it is working, someone sharing the coffee shop Wi-Fi with you cannot read the bytes of your upload, and cannot quietly modify them on the way through.
This is the baseline. It is also the easiest to verify yourself: if the site loads over HTTPS and does not throw certificate warnings, transit encryption is present. Any tool without it in 2026 should be closed immediately. But transit encryption ends the moment the data reaches the server. It says nothing about what happens next.
Stage two: encryption at rest
Encryption at rest means the stored copy on the server's disk is encrypted rather than sitting there as a plain readable file. Its real-world purpose is narrower than people assume: it protects against someone obtaining the physical storage or a raw database dump without also obtaining the keys.
What it does not do is hide the file from the service itself. If the service can decrypt the file to serve it to your recipient, then the service, by definition, holds the ability to decrypt it. At-rest encryption is a real and worthwhile control, but it is a control against theft of storage, not a promise of provider blindness.
Stage three: end-to-end encryption
End-to-end encryption is the strong claim. It means the file is encrypted on the sender's device with a key the server never receives, and decrypted only on the recipient's device. The server stores an unreadable blob. Even a fully compromised server, or a subpoena served on the operator, yields nothing but ciphertext.
The tell for genuine end-to-end encryption is key handling. If the tool can show you a preview of your file, generate a thumbnail, scan it for viruses server-side, or let you recover access after losing the key, then it is not end-to-end encrypted in the strict sense. Those features require the plaintext. You cannot have both.
The honest trade-offs
- End-to-end encryption breaks recovery. Lose the key and the data is mathematically gone. There is no support ticket that fixes this.
- End-to-end encryption breaks server-side features: search, preview, deduplication, malware scanning.
- Browser-based end-to-end encryption depends on the JavaScript the server sends you each visit, which is a weaker guarantee than an audited installed application.
- At-rest encryption plus strict access control and short retention is, for most everyday sharing, a more realistic and more usable posture than an awkward end-to-end setup that people work around.
Where the real risk usually is
Encryption is rarely the weak link. The weak link is access control and lifetime. A perfectly encrypted file behind a link that never expires and requires no code is less safe than an at-rest-encrypted file behind a four-digit code that dies in an hour. Attackers do not break AES; they find the link in a Slack channel, or in a browser history, or in a forwarded email.
This is why retention policy deserves as much attention as the cipher. Ask how long the file is kept, whether it is deleted or merely marked inaccessible, whether backups retain it after deletion, and whether logs record the filename indefinitely.
Questions worth asking a provider
- Is the file encrypted at rest, and who holds the decryption keys?
- Can your staff read the contents of a stored file if they choose to?
- When a file expires, is it deleted from primary storage, and when does it leave backups?
- Is the filename or any metadata retained after the file itself is removed?
- Is access gated by a secret the recipient must supply, or by possession of a URL alone?
- Is there a rate limit on guessing that secret?
Reading marketing language critically
Bank-grade encryption means nothing; banks use standard TLS like everyone else. Military-grade usually means AES-256, which is also what your phone's lock screen uses. Zero-knowledge is a meaningful term but is frequently misapplied to systems where the server holds keys. Secure by design is a slogan. Look instead for specific, falsifiable statements: which algorithm, which stage, who holds keys, what the retention period is.
A sensible default for normal people
For everyday transfers, aim for: HTTPS throughout, encryption at rest, an access code rather than a bare link, a short expiry measured in hours, and deletion after expiry. Reserve true end-to-end tooling for the small set of files where a provider compromise would be genuinely damaging, and accept the usability cost consciously when you do. Understanding the difference is the point; the goal is not maximum paranoia, it is knowing exactly what you are and are not protected from.
A quick worked example
Imagine sending a scanned passport. With transit encryption only, the coffee shop cannot read it, but the server stores a readable copy that any operator with disk access could open. Add at-rest encryption and a stolen backup tape is useless, though the running service can still decrypt on demand. Add a short access code and a two-hour expiry and the window in which any of that matters shrinks to two hours. Add true end-to-end encryption and even a fully compromised server yields nothing — but you also lose recovery, previews and any server-side safety checks, and you must transport the key yourself.
Laid out like that, the decision stops being about which product sounds most secure and becomes a straightforward question about which failure you are actually trying to prevent.