Client-side vs server-side encryption for secure links
Why encryption architecture matters
When you use a secure link tool to share a password, the secret travels from your browser to a server and then to the recipient. Encryption determines how exposed the secret is during and after that journey. But not all encryption is equivalent — the location where encryption happens makes a significant difference to your security model.
Server-side encryption explained
In server-side encryption, your secret is transmitted to the server in plain text (or lightly protected by HTTPS), and the server encrypts it before storing it. When the recipient retrieves the secret, the server decrypts it and delivers it.
What this means in practice:
- The server operator can technically read your secret
- A server breach could expose decrypted data if keys are stored alongside data
- You are trusting the service provider's security practices entirely
- HTTPS protects the secret in transit between browser and server
This model is simpler to implement and covers the most common threat: secrets sitting unprotected in databases or email archives.
Client-side encryption explained
In client-side encryption, your browser encrypts the secret before it leaves your device. The server only ever stores an encrypted blob. When the recipient opens the link, their browser decrypts it — often using a key embedded in the link's URL fragment (the part after #), which is never sent to the server.
What this means in practice:
- The server operator cannot read your secret, even theoretically
- A server breach exposes only encrypted data that is useless without the key
- The key is typically part of the link itself, so keeping the link secure is critical
- More complex to implement correctly; subtle implementation flaws can undermine the model
The practical comparison
| Property | Server-side encryption | Client-side encryption |
|---|---|---|
| Server operator can read secret | Yes (in principle) | No |
| Protection if server is breached | Depends on key management | Strong (if implemented correctly) |
| Protection in transit (HTTPS) | Yes | Yes |
| Implementation complexity | Lower | Higher |
| Link URL contains decryption key | No | Often yes |
| Trust required in provider | High | Lower |
The nuance: HTTPS + server-side encryption is often sufficient
For most credential sharing scenarios, a well-implemented server-side encrypted tool with HTTPS provides adequate security. The threat model for most teams is not "the service provider is reading our passwords" — it is "passwords are sitting in email threads and Slack channels in plain text."
Moving from email to any properly built one-time link tool, regardless of encryption architecture, eliminates the most common risks.
When client-side encryption is worth prioritising
Client-side encryption is the right choice when:
- You are sharing secrets with very high sensitivity (private keys, financial credentials)
- You have regulatory requirements that demand end-to-end confidentiality
- You cannot accept any theoretical risk of provider access to your data
- You are in a jurisdiction with strong data sovereignty requirements
What PassTransfer does
PassTransfer encrypts secrets in your browser with AES-GCM (WebCrypto) before they reach the server, so the server only ever stores ciphertext it cannot read. Secrets are deleted immediately after retrieval and never appear in logs. HTTPS protects all data in transit.
For the typical business credential — a CMS login, a hosting account, a client handover — this provides strong, practical security without the implementation complexity of client-side encryption.
