Client-Side Encryption

Anyone who uploads a file to online storage normally hands it over in plain text. The provider can read it there, even if it usually doesn’t. With Client-Side Encryption, things run the other way around. The file is first converted into an unreadable string of characters on the user’s own device. This conversion is called encryption, and it can only be reversed with a matching key. Only afterwards does the file leave the device, and the key stays with the user. The provider therefore only gets to see something it can do nothing with.

When even the provider can’t read along

The decisive point is who holds the key. With typical cloud services, the data is indeed stored encrypted on the hard drives, but the provider manages the key itself. It could decrypt at any time. That is exactly what is technically ruled out with Client-Side Encryption. Experts also call this zero-knowledge: the service knows nothing about the content it stores.

This changes the situation in the event of a break-in. If a data center is hacked, attackers only capture useless strings of characters. Even an authority demanding data from the provider gets nothing readable. For hospitals, law firms, or journalists, this difference is crucial. Data protection laws like the GDPR assess such data much more leniently, because a leak remains practically without consequence.

The flip side is inconvenient. Anyone who loses their key or the associated password loses the data for good. There is no support that can restore it, because even the provider has no access. Many services therefore offer an emergency code that you’re supposed to print out and keep safe.

From password to key and back

Technically, everything starts with the user’s password. From it, the app on the device computes a key, usually a long random number. This process is deliberately built to be slow, so that attackers can’t try millions of passwords per second. The password itself is never sent to the server.

With this key, the app encrypts the file before it is uploaded. The common method is AES, which is also used by banks and governments. When downloading, everything runs in reverse: the encrypted block arrives, the device decrypts it locally, and the user sees their text again. The server has handled nothing but data jumble the whole time.

Things get tricky when sharing. If a second person is supposed to read the file, they need the key. For this, a second method is used, with a public and a private key part. The file key is wrapped with the recipient’s public part and sent along. Only their private part can open the package again.

Password managers, messengers, and the fight over the cloud

The principle is best known from password managers like Bitwarden or 1Password. They store login credentials in the cloud but can’t view them themselves. Messengers like Signal or WhatsApp also work on the same basic idea, there it’s called end-to-end encryption. The only difference is the direction: once between user and storage, once between two conversation partners.

With cloud storage, it’s an option, not the standard. Apple calls it Advanced Data Protection, Google offers it to paying business customers. Providers like Tresorit or Proton have built it in from the start and advertise it. It isn’t the standard because convenience features fall away: full-text search across encrypted files is difficult, and a preview in the browser is often impossible.

In the news, the term regularly comes up in disputes over surveillance. Governments demand access for investigators, while experts counter that a backdoor left open for anyone is open to everyone. In 2025, Apple withdrew its Advanced Data Protection in the United Kingdom following such an order. A common misconception, by the way, is that the padlock icon in the browser is already enough. It only protects the transport path, not the data on the server.