When you upload a file to most cloud services, the file travels from your browser to the server in plaintext (protected only by TLS in transit), and the server decides how — or whether — to encrypt it. The service provider holds the encryption keys. They can decrypt your data at any time, whether for internal processing, compliance requests, or because an attacker gained access to their infrastructure.
Client-side encryption changes this model entirely. Your files are encrypted in the browser, on your device, before they leave your machine. The server receives only ciphertext — encrypted data that is meaningless without the key, which only you control.
How Client-Side Encryption Works
The process follows a straightforward sequence:
1. Key Derivation
When you set a password, the browser derives a cryptographic key from it using a key derivation function (KDF). Modern implementations use PBKDF2 or Argon2 with a high iteration count — typically 600,000 iterations or more for PBKDF2. This process is intentionally slow to resist brute-force attacks against the password.
The derivation also uses a random salt — a unique value generated for each encryption operation. The salt ensures that the same password produces different keys each time, preventing precomputed dictionary attacks.
2. Encryption
With the derived key, the browser encrypts your file using a symmetric encryption algorithm. AES-256-GCM is the current standard:
- AES-256 refers to the Advanced Encryption Standard with a 256-bit key. It is approved by NIST and used across government, financial, and healthcare systems worldwide.
- GCM (Galois/Counter Mode) is an authenticated encryption mode. It does not just encrypt the data — it also generates an authentication tag that detects any tampering with the ciphertext.
The encryption produces three outputs: the ciphertext (encrypted file data), an initialization vector (IV), and an authentication tag. The IV ensures that encrypting the same file with the same key produces different ciphertext each time.
3. Upload
Only the ciphertext, IV, salt, and authentication tag are sent to the server. The password and derived key never leave your browser. The server stores the encrypted blob without any ability to read its contents.
4. Decryption
When the recipient accesses the file, they enter the same password in their browser. The browser re-derives the key using the stored salt, then decrypts the ciphertext locally. If the password is wrong, decryption fails — the authentication tag will not validate, and the data remains inaccessible.
Client-Side vs. Server-Side Encryption
The distinction matters more than most people realize.
| Aspect | Server-Side Encryption | Client-Side Encryption |
|---|---|---|
| Who holds the key | The service provider | The user |
| When encryption occurs | After upload, on the server | Before upload, in the browser |
| Server can read data | Yes | No |
| Compromised server exposes data | Yes | No (only ciphertext is exposed) |
| Provider can comply with data requests | Yes, they can decrypt | No, they cannot decrypt |
| Key management complexity | Provider handles it | User manages the password |
Server-side encryption protects data at rest on disk, but the provider has full access to plaintext during processing. This means a breach of the provider’s infrastructure, a rogue employee, or a legal order can expose your data.
Client-side encryption eliminates the provider from the trust model. Even if the server is fully compromised, the attacker obtains only encrypted blobs. Without the user’s password, the data is computationally inaccessible.
Where TLS Fits In
A common misconception is that HTTPS (TLS) provides sufficient encryption for file sharing. TLS encrypts data in transit — between your browser and the server. It prevents network eavesdropping and man-in-the-middle attacks. But TLS terminates at the server. Once your data arrives, TLS has no further role. The server receives and processes your data in plaintext.
Client-side encryption and TLS serve different purposes:
- TLS protects the transport layer (your data on the network)
- Client-side encryption protects the data itself (regardless of where it is stored or transmitted)
A properly secured system uses both. TLS protects the encrypted payload in transit. Client-side encryption ensures the payload is meaningless to anyone without the password, including the server itself.
The Browser as a Cryptographic Environment
Modern browsers provide the Web Crypto API — a native, hardware-accelerated cryptographic interface. This means client-side encryption does not require any plugins, extensions, or downloads. The browser itself performs key derivation, encryption, and decryption using well-audited, standards-compliant implementations.
Key properties of the Web Crypto API:
- Non-extractable keys. Cryptographic keys can be generated in a way that prevents JavaScript from reading the raw key material, reducing the risk of key theft through XSS attacks.
- Hardware acceleration. AES operations leverage CPU instruction sets (AES-NI on modern processors), making encryption fast even for large files.
- Standards compliance. The API implements NIST-approved algorithms, ensuring interoperability and auditability.
What to Look For in Client-Side Encryption Tools
Not all tools claiming client-side encryption implement it correctly. When evaluating a solution, verify:
- The encryption algorithm and mode. AES-256-GCM is the current standard. Avoid tools using older modes like ECB or CBC without authentication.
- The key derivation function and iteration count. PBKDF2 with at least 600,000 iterations, or Argon2id. Low iteration counts make passwords vulnerable to brute-force attacks.
- That the key never leaves the client. Check whether the password or derived key is transmitted to the server. If it is, the encryption is not truly client-side.
- Authentication of ciphertext. GCM mode provides this automatically. Without authenticated encryption, an attacker could modify the ciphertext without detection.
- Unique salts and IVs per operation. Reusing salts or initialization vectors can compromise the encryption, even with a strong algorithm.
Why It Matters for Secret Sharing
When sharing sensitive files — credentials, API keys, configuration files, legal documents — the security of the sharing mechanism is only as strong as its weakest point.
If the server can read your data, you are trusting the provider’s security practices, access controls, employee vetting, and incident response capabilities. You are also trusting that they will not be compelled to hand over your data by a legal order.
Client-side encryption reduces this trust requirement to a single point: the password you choose. A strong password, combined with a high-iteration key derivation function and AES-256-GCM encryption, makes your data computationally inaccessible to anyone who does not know the password — including the service provider.
For developers sharing secrets across teams, clients, and environments, this is not a theoretical advantage. It is the difference between “we trust our tools” and “our tools are designed so trust is not required.”