Client side encryption explained: why the server should never see your password

What client side encryption is, and why it matters for office software

Every day, European companies send files that should stay private: a signed contract, a salary overview, a patient file, a set of legal documents. Most of the time, that file travels through a mail attachment or a file transfer tool. Somewhere between your laptop and the recipient's, that file sits on a server owned by someone else.

The question worth asking is simple: while the file sits on that server, who can open it?

With most tools, the honest answer is: the provider can, if it wants to or if it is legally forced to. The file arrives on the server as plain, readable data. The provider encrypts it for storage, which protects against a stolen hard disk, but the provider holds the key. If a government agency serves that provider with a valid order, the provider can decrypt the file and hand it over, because it has both the data and the key.

Client side encryption changes that order of operations. Instead of encrypting the file after it lands on the server, the file is encrypted in your browser or on your device, before it ever leaves. The server only ever receives and stores scrambled data. The key that unlocks it is never sent along. Without that key, the provider is holding a locked box it cannot open, no matter who asks.

This is not an exotic concept. It is the same idea behind a sealed envelope versus a postcard. A postcard can be read by anyone who handles it along the way. A sealed envelope can only be read by someone who has the key, or in this case, the password, and that password is never written on the envelope itself.

For a European company deciding where to send confidential files, understanding this distinction matters more than it used to. The reason is legal, not just technical, and it is worth spelling out before we look at how the encryption itself works.

How it actually works: the data flow from browser to storage

Walk through what happens when someone uses a properly built client side encryption system to send a confidential file to another company.

Step 1: the file is selected, but not yet uploaded. The sender picks a file on their computer and opens it in their browser, on a page provided by the sending company's own domain.

Step 2: a password is set. The sender either creates a password or the system generates one. This password never travels to the server as part of the upload. It is kept separate from the file entirely.

Step 3: the browser does the encryption, locally. Using the password, the browser's own code scrambles both the file's name and its contents, right there on the sender's machine, before a single byte goes anywhere. This step happens with JavaScript running in the browser, using the password to derive an encryption key, and using that key to turn the readable file into unreadable ciphertext.

Step 4: only ciphertext is uploaded. What reaches the server is the scrambled version. The server stores it, counts it against storage quotas, applies retention rules, but it cannot read the file name or the contents, because it never had the key.

Step 5: the password travels separately. The sender shares the password with the recipient through a different channel entirely, for example a phone call, a text message, or a separate email. This separation is the whole point: if the file and the password travelled together, anyone intercepting one communication would have both.

Step 6: the recipient's browser does the decryption. The recipient opens the link, enters the password, and their own browser downloads the ciphertext and turns it back into the original file, locally, on their machine. The server hands over scrambled data and plays no part in unlocking it.

Step 7: the file expires and disappears. After a set number of days, the server deletes the ciphertext. There is nothing left to request, even if someone wanted to.

Notice what the server never does at any point in this flow: it never sees the file name in readable form, it never sees the contents, and it never sees or stores the password. An administrator looking at the storage system sees a transfer exists, who sent it, roughly when it expires, but not what is inside it.

A concrete example: encrypted file transfer in practice

Picture an HR manager at a mid-sized company who needs to send an external accountant a spreadsheet containing twelve employees' salary details. The old habit is to email it as an attachment, maybe with a password on the Excel file itself, maybe not.

With a client side encrypted transfer tool, here is what the exchange looks like in practice:

• The HR manager opens a page on the company's own domain, for example a "Receive" or "Send" page tied to their Workspace account.
• She drags the spreadsheet in. The browser encrypts it immediately, before upload starts. A transfer can include up to 100 files and 10 GB in total, which is more than enough for a spreadsheet.
• She sets the file to expire in 7 days rather than the default 14, since the accountant only needs same-week access.
• She sends the accountant a link by email, and separately, by a quick phone call, reads out the password.
• The accountant opens the link, types in the password, and the spreadsheet downloads and decrypts locally in his browser.
• Seven days later, the file is deleted from the server automatically. There is nothing left to subpoena, lose in a breach, or forget about.

Compare that to the common alternative many companies still use for this kind of exchange, a tool like Cryptshare, or simply emailing a password-protected zip file. The mechanics look similar on the surface, but the question that matters is where the decryption key sits during the time the file is stored. If the provider can technically produce the original file on request, because it processed the password server-side at some point, that is not client side encryption, even if the marketing uses the word "encrypted."

This is also the model used by Binadit Workspace's Receive feature, which exists specifically to replace tools like Cryptshare for European companies: names and contents are encrypted in the sender's browser before upload, the password travels through a separate channel, and the password cannot be recovered by anyone, including Binadit itself.

Trade-offs and design decisions worth understanding

Client side encryption is not free. It comes with real trade-offs, and a good engineer or IT manager should understand them before assuming it is the right tool for everything.

You cannot search inside encrypted content

If a server never sees the plain content of a file, it cannot index it for search, cannot generate a preview thumbnail, and cannot scan it for malware on the server side. This is a reasonable price to pay for a one-off confidential transfer, but it is a poor fit for a document library that teams need to search through daily. That is why file transfer tools use client side encryption, while day-to-day document collaboration tools like Google Docs or an office suite generally do not: the collaboration itself requires the server to understand the content.

If the password is lost, the data is gone

Because the provider never holds the key, there is no "forgot password" recovery option for client side encrypted content. This is by design, not an oversight. Any recovery mechanism that lets a provider regenerate or reset the key is, functionally, a second way in, and a second way in is also a way a government order can walk through. A clean client side encryption design has to accept that lost passwords mean lost data, and communicate that clearly to users.

It protects data in transit and at rest, not the endpoints

Client side encryption protects the file while it sits on someone else's server. It does nothing to protect the sender's laptop if that laptop is compromised, and it does nothing to stop the recipient from forwarding the decrypted file to someone else once they have opened it. It is one layer in a broader approach to data protection, not a complete answer by itself.

It is not the same as end-to-end encrypted mail

It is worth being precise here, because the terms get blurred often. Ordinary business mail, including mail hosted in Europe, is typically encrypted in transit (so it cannot be read on the wire) and encrypted at rest on the server (so a stolen disk is useless), but the mail provider itself can still technically read the message, because it holds the decryption key for storage. That is a meaningfully different, and weaker, guarantee than client side encryption, where the provider never holds the key at all. A European mail provider closing the jurisdiction gap is valuable and worth understanding on its own terms, which is covered in more depth in this piece on whether your email will still be GDPR compliant next year, but it should not be confused with client side encryption for file transfers.

Where the jurisdiction question actually bites

This distinction matters because of how the US CLOUD Act works. Enacted in March 2018, it requires a provider under US jurisdiction to turn over data in its "possession, custody, or control," regardless of where the server physically sits, as long as valid US legal process exists, such as a warrant or a court order. The law follows the company, not the data centre.

That is precisely why client side encryption matters so much for sensitive one-off transfers. If a US-headquartered provider is served with a valid order for a file, and that provider genuinely has no technical way to decrypt it, because the key never left the sender's browser, there is nothing readable to hand over. The legal reach of the CLOUD Act is real, but it only produces readable data if the provider holds the key. Client side encryption removes that possibility entirely, by design, rather than by policy promise.

This is a narrower and more concrete point than the general debate about where servers are physically located. Choosing a European data region for a US company's product decides where the bytes sit, not which country's law the provider answers to. Client side encryption sidesteps that question for the specific data it protects, because there is nothing for any jurisdiction's court order to unlock.

When to use client side encryption, and when not to

Use client side encryption when:

• You are sending a specific, sensitive file to someone outside your organisation: salary data, legal documents, medical records, a signed contract.
• The data has a short shelf life once delivered, so automatic deletion after a set number of days is acceptable or even desirable.
• You do not need the server to search, preview, or scan the content.
• You want a mechanism where "we could not hand it over even if ordered to" is literally true, not a policy statement.

Do not reach for client side encryption when:

• You need ongoing collaboration on a document with multiple people editing it live. The server needs to understand the content to merge changes, which conflicts with never seeing plain content.
• You need the content indexed and searchable later, for example in a shared team drive used daily.
• You need automated virus scanning on upload, which requires the server to inspect the file.
• The audience for the file is large and ongoing, rather than a one-off exchange, in which case proper access control and a European-hosted drive with encryption at rest is usually the more practical layer.

In other words, client side encryption is the right tool for the moment data leaves your organisation's control and needs to arrive intact and unread by anyone in between. It is the wrong tool for the data your own team needs to work with daily. A sound setup uses both: encryption at rest and strong access control for day-to-day files, and client side encryption specifically for the one-off, sensitive handoffs to outside parties.

If you are evaluating a Microsoft 365 alternative or a European alternative to Google Workspace for broader reasons, the same logic applies at a larger scale: understand exactly which parts of the system the provider can technically read, and which parts it cannot, rather than taking "encrypted" at face value in a spec sheet.

Further reading and where Binadit fits in

Client side encryption is one piece of a larger question many European IT managers and privacy officers are working through right now: not just how individual files are protected, but which law actually governs the provider holding your organisation's day-to-day data. If you want the fuller legal picture behind that question, including what the CLOUD Act requires and what GDPR says about transfers outside the EU, see how to ask your cloud act email provider the right questions, in writing. For a structured way to check your own exposure across providers, a 12-question sovereignty audit every DPO should run is a useful companion piece.

Binadit Workspace is built by Binadit B.V. in Rotterdam, a Dutch company with no foreign parent, running every server in Dutch data centres under its own management. Its Receive feature uses client side encryption exactly as described above, as a direct replacement for tools like Cryptshare or ad-hoc password-protected attachments, alongside mail, calendar, drive, office documents, video meetings and scheduling on your own domain. If you want to see how it fits your organisation's file transfer habits specifically, ask for a demo and a quote.