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 property often called zero-knowledge encryption
- 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: the biggest win comes earlier
For most teams, the threat model 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, already eliminates the most common risks: see our complete guide to secure password sharing for the full threat model.
That does not make the distinction academic. Once you have made that move, client-side encryption is what decides whether you still have to trust your provider at all, at no extra cost to you as a user.
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
Correction, September 2026: an earlier version of this article described PassTransfer as a server-side model. That was accurate until July 2026. PassTransfer has encrypted client-side since, and the text below describes how it works now.
PassTransfer encrypts in your browser, before anything is sent to us. Your browser generates a random key, encrypts your password and the sender name with AES-GCM, and puts that key after the # in the link. Browsers never send the part of a URL after the hash to the server, so we do not receive it, not even in our logs.
What we store is the encrypted value and the moment the link expires. Nothing else. On retrieval we hand that value back and delete it in the same operation; the recipient's browser decrypts locally. We cannot read the contents at any point.
Two consequences complete the honest picture.
Lost is lost. Because we do not hold the key, we cannot recover a secret for you. Lose the link and the contents are gone for good. That is not a shortcoming but the price of the model.
No HTTPS, no encryption. If your browser cannot encrypt securely, the form refuses to submit. There is no silent fallback to a server-side path: that would undermine the very guarantee you came here for.
The caveat that applies to every browser-based E2EE
Client-side encryption in a browser means the provider ships the code that performs the encryption. That is as true for us as it is for every other web-based tool. If you would rather not make that assumption, a locally installed tool with an audited client is the right answer, not a website. That is a legitimate choice and we will not pretend otherwise. If you have questions about our security model, email us at hello@passtransfer.com.
