Server-side encryption encrypts data on the server after receiving plaintext, requiring trust in the service provider. Client-side encryption encrypts data in your browser before sending, so the server never sees plaintext. For secret sharing, client-side encryption is more secure because it eliminates the service as a point of trust — even a compromised server cannot read your data.

This post compares both approaches: how they work, what each one asks you to trust, and where the real trade-offs lie. This is not an argument for one side — it is a framework for evaluating which model fits your threat model.

For a quick overview of why client-side encryption matters, see our earlier post. For a detailed look at Vaulted's specific implementation, see our zero-knowledge deep-dive.

How server-side encryption works

In the server-side model, the service handles encryption on your behalf. The typical flow:

You enter a secret in the browser
Your browser sends the plaintext to the server over TLS
The server encrypts the data using a key it manages
The ciphertext is stored in the database
When the recipient requests the secret, the server decrypts it and returns the plaintext

The encryption key never leaves the server. It might live in a hardware security module (HSM), a cloud key management service (KMS), or a configuration file — but the server controls it completely.

The server-side trust model

With server-side encryption, you are trusting:

The service operator not to read your data (they have the key and the plaintext in memory during encryption/decryption)
The infrastructure not to be breached (a compromised server exposes both keys and data)
The operator's employees not to abuse access (anyone with server access can potentially read secrets)
The legal jurisdiction not to compel disclosure (the operator can be forced to hand over data because they hold the keys)
Server logs and monitoring not to capture plaintext (logging frameworks can inadvertently record sensitive data)

This is not necessarily a bad model. Many services use it successfully — cloud storage, email providers, and database services all rely on server-side encryption. The question is whether the trade-off fits your use case.

How client-side encryption works

In the client-side model, encryption happens in the browser before any data reaches the server. The flow is different:

You enter a secret in the browser
The browser generates an encryption key and encrypts the data locally
Only the ciphertext is sent to the server
The encryption key is delivered to the recipient through a separate channel (typically the URL fragment)
The recipient's browser decrypts the ciphertext locally

The server never sees the plaintext and never holds the encryption key. It stores and retrieves encrypted blobs — nothing more.

Vaulted uses this model. Each secret gets a fresh AES-GCM key with a 256-bit key length. The key is placed in the URL fragment (#), which browsers never include in HTTP requests per RFC 3986. The server receives the ciphertext and a 12-byte random IV for storage, but the key stays entirely in the link shared between sender and recipient.

The client-side trust model

With client-side encryption, you are trusting:

The browser to implement cryptography correctly (the Web Crypto API delegates to native crypto engines like BoringSSL or NSS)
The application code to actually perform encryption client-side (you can verify this by inspecting network requests)
The link delivery channel to be secure (anyone with the full URL, including the fragment, can decrypt the secret)
The recipient's device not to be compromised (after decryption, malware or screen capture can access plaintext)

You are not trusting the server, the service operator, their employees, or their legal jurisdiction. The server is a storage relay for encrypted data it cannot read.

Comparing the trade-offs

Neither model is universally better. Each makes different trade-offs between security, usability, and feature richness.

Security properties

Property	Server-side	Client-side
Server breach exposure	Keys + ciphertext exposed	Only ciphertext exposed (useless without keys)
Operator can read data	Yes (holds keys)	No (never has keys)
Legal compulsion risk	Operator can comply (has access)	Operator cannot comply (does not have access)
Link interception risk	Not applicable (no key in link)	Full URL = full access (mitigated by passphrase)
Man-in-the-middle	TLS protects transit; server sees plaintext	TLS protects ciphertext; key in fragment never sent

Usability properties

Property	Server-side	Client-side
Key management burden	None for user (server handles it)	User must share link securely
Password recovery	Possible (server holds keys)	Not possible (keys only in link)
Search and indexing	Server can search plaintext	Not possible without decryption
Sharing flexibility	Server can re-encrypt for new recipients	Requires new link per recipient
Offline access	Requires server connection to decrypt	Possible if ciphertext and key are cached locally

Feature trade-offs

Feature	Server-side	Client-side
Audit logging of content	Possible	Not possible (server cannot read content)
Content-based policies	Possible (DLP, compliance scanning)	Not possible without decryption
Key rotation	Server can re-encrypt with new keys	Requires regenerating and resharing links
Multi-party access control	Server can manage per-user keys	Each recipient needs the key directly
Zero-knowledge guarantee	No	Yes

When server-side encryption is acceptable

Server-side encryption is a reasonable choice when:

You trust the service operator and their security practices
You need features that require server-side access to data (search, sharing, compliance scanning)
The data sensitivity does not justify the usability cost of client-side encryption
You operate in a regulated environment where the operator's compliance certifications matter more than zero-knowledge guarantees
Key management complexity needs to be handled by the service, not the user

Cloud storage services, enterprise email, and managed database encryption all use this model effectively.

When client-side encryption is necessary

Client-side encryption becomes necessary when:

You cannot or should not trust the service operator with your data
The data is sensitive enough that a server breach must not expose plaintext
You need a zero-knowledge guarantee — mathematical proof that the server cannot read your data
Legal or compliance requirements demand that the service operator have no access to content
You want protection against insider threats at the service provider

Secret sharing is one of the strongest use cases for client-side encryption. The data is inherently sensitive (passwords, API keys, credentials), the sharing is transient (view-limited, time-limited), and the trust relationship is minimal (you may not know or trust the service operator).

How Vaulted approaches this

Vaulted uses client-side encryption exclusively. Every secret is encrypted in the browser with a fresh AES-GCM key before any data reaches the server. The key travels only in the URL fragment, and optional passphrase protection adds a second layer through PBKDF2 key derivation and AES-KW key wrapping.

The server stores encrypted ciphertext with a time-to-live and a view counter. It cannot decrypt, search, or inspect the content. A complete database breach yields only encrypted blobs — computationally useless without the keys that exist only in the shared links.

For the full cryptographic details — key generation, IV handling, passphrase wrapping, and the exact Web Crypto API calls — see our zero-knowledge encryption deep-dive.

Making your choice

The right encryption model depends on what you are protecting and who you are willing to trust.

If you need features like search, recovery, or centralized key management, server-side encryption is the practical choice. If you need a guarantee that no one — not the service, not its employees, not a court order — can read your data, client-side encryption is the only model that provides it.

For sharing secrets, the answer is straightforward: the data is sensitive, the interaction is brief, and the fewer parties that can access plaintext, the better.

Ready to share a secret with zero-knowledge encryption? Create a secret on Vaulted — your data never leaves your browser unencrypted.

Why Client-Side Encryption Matters — the case for encrypting in the browser
Zero-Knowledge Encryption: How Vaulted Keeps Your Secrets Private — deep-dive into the cryptographic implementation
Security at Vaulted — summary of our security model

Server-Side vs. Client-Side Encryption: Which Model Should You Trust?