Storage providers describe encryption with three recurring phrases: in transit, at rest, and end-to-end. They are not degrees of the same thing - they are three different protections against three different failures, and knowing which is which turns marketing pages into information.
Encryption in transit: protecting the journey
In transit means the connection between your device and the storage is encrypted - TLS, the same mechanism as the padlock in your browser. It defends against anyone positioned along the network path: the coffee shop wifi, a compromised router, an internet exchange somewhere in the middle.
What it covers ends when the journey does. Data protected only in transit arrives, is decrypted, and exists at the destination in whatever state the destination keeps it.
This one is table stakes. Any service without TLS everywhere, in 2026, is disqualified before the comparison starts.
Encryption at rest: protecting the hardware
At rest means the data is encrypted on the physical disks it occupies, using keys managed by the infrastructure. The failure it defends against is physical: a drive pulled from a rack, a decommissioned server sold on, a misplaced backup volume. Whoever ends up holding the hardware holds ciphertext.
At rest is the baseline any serious provider should meet, and most do. Files here are encrypted in transit and at rest as exactly this kind of unremarkable baseline.
What the phrase does not describe is anything about accounts, applications or process - it is a statement about disks. Encryption at rest does not make a weak password stronger, which is why account security - two-factor authentication and unique passwords - matters more in practice than any label on the storage layer.
End-to-end: moving the key to your device
End-to-end encryption changes where the key lives. A key is derived on your own device from something only you know; files become ciphertext before they leave, and what is stored stays ciphertext. The scope of the protection stops depending on the destination at all, because what the destination holds is unreadable without key material that never left you.
We offer this as Vault: a separate, opt-in space where the key is derived on-device from your passphrase, with a recovery code as the second door. The Vault page describes the mechanics, and what zero-knowledge storage actually means walks the full detail, including how key derivation and wrapping work.
The trade-offs are structural, not implementation quirks. Search, previews and thumbnails require reading content, so inside an end-to-end space they move on-device or stop existing. Protocol access - WebDAV, S3, SFTP - assumes a server that can hand over bytes on request, so it cannot apply to end-to-end files. Sharing must be modelled cryptographically rather than granted with a URL. And key material you alone hold is key material only you can lose: no reset, no recovery ticket. That last property is the guarantee working as designed.
This is why end-to-end is offered as a distinct space rather than a switch applied to everything: the two models cannot coexist on the same file, and most files are better served by the features than by the ceremony.
Matching the protection to the file
The three protections stack rather than compete, so the practical question is what the file in front of you needs.
Everything gets in transit and at rest without you deciding anything - that is the baseline doing its job.
Most working files stop there, and should. They keep search, previews, sharing links and protocol access, and the risks that actually materialise - reused passwords, phishing, accidental deletion - are addressed by account hygiene and version history, not by more cryptography.
A small set justifies end-to-end: identity documents, legal and medical material, unreleased work, anything where you want the guarantee to be a property of mathematics rather than a feature of operations. Put those in the Vault, store the recovery code somewhere that survives you losing a device, and accept the trade-offs knowingly.
The mistake worth avoiding is treating the three phrases as a ladder where more is automatically better. They are answers to different questions - and the file you are about to store already knows which question it is asking.
Frequently asked questions
What is the difference between encryption at rest and end-to-end?
At rest means data is encrypted on the disks it occupies, using keys managed by the infrastructure, which protects against physical hardware exposure. End-to-end means the key is derived on your own device, and what is stored is ciphertext.
What does encryption in transit protect against?
Anyone positioned along the network path between your device and the storage, such as an open wifi network or a compromised router. It is TLS, the same protection as the padlock in your browser.
Should I encrypt all my files end-to-end?
Usually not. End-to-end encryption removes search, previews and protocol access, and losing your key material means losing the data. Reserve it for genuinely sensitive material and keep the features for everything else.
