scryp
All posts
8 min read

Server-Side vs. Client-Side Encryption: The Decisive Difference

Almost every transcription service advertises “encryption.” But not every form of encryption protects equally well. The decisive difference does not lie in the algorithm – but in who holds the key.

This article explains the difference between server-side and client-side encryption and why it makes a fundamental difference for your audio files.

What “encryption at rest” really means

“Encryption at rest” means: data is stored encrypted. The catch: the provider holds the key. Every employee with database access, every cloud administrator and every hacker who compromises the server can decrypt the data.

Most cloud services encrypt data once it is on disk. This protects against the theft of physical hard drives – a scenario that rarely occurs at professional data centers. It does not protect against:

  • Attacks on the application: Anyone who breaks into the application has access to the decryption function.
  • Insider access: The provider’s administrators can read the data at any time.
  • Government requests: The provider can decrypt the data and hand it over.
  • AI training: The provider could use your data to improve its models.

In short: server-side encryption protects the hard drive, not your data.

What client-side encryption does differently

With client-side encryption, your audio file is encrypted in the browser before it reaches the server. The server stores only encrypted blobs – it does not hold the key. Not even the provider can read the stored data.

The process in detail:

  • 1. Generate a key: For each file, a dedicated 256-bit key is generated in the browser (File Encryption Key).
  • 2. Encrypt locally: The audio file is encrypted with AES-256-GCM directly in the browser. The server receives only encrypted bytes.
  • 3. Secure the key: The file key is encrypted with your personal master key and stored on the server that way. Without your password, no one can access it.

The result: only encrypted data ever sits on the server. No employee of the provider, no hacker and no authority can decrypt it without your key.

The direct comparison

The following table shows the difference at a glance:

  • Who encrypts? Server-side encryption: the provider. Client-side encryption: your browser.
  • Who holds the key? Server-side encryption: the provider. Client-side encryption: only you.
  • Can the provider read it? Server-side encryption: yes. Client-side encryption: no.
  • Protection in the event of a breach? Server-side encryption: limited (the key is often compromised too). Client-side encryption: complete (the key is not on the server).
  • Disclosure to authorities? Server-side encryption: the provider can decrypt. Client-side encryption: the provider can only supply encrypted blobs.
  • GDPR Art. 34(3)(a)? Server-side encryption: notification obligation in the event of a breach. Client-side encryption: no notification obligation, because the data is unreadable.

What is stored on the server

With client-side encryption, only encrypted data is permanently stored on the server. The transcript is stored encrypted and can be decrypted only by the user themselves. Original audio files are automatically deleted after processing – only an encrypted playback version remains on the server.

The result: even we, as the provider, cannot read the stored transcripts and audio files.

How to tell which type of encryption a service uses

If a transcription service says “your data is encrypted,” ask specifically:

  • “Who holds the decryption key?”– If the provider holds it, it is server-side encryption.
  • “Can your employees read my transcripts?” – With honest providers using server-side encryption, the answer is: theoretically yes.
  • “What happens in the event of a data breach?”– If the provider mentions notification obligations under Art. 34 GDPR, that points to decryptable data.
  • “Can I verify the encryption myself?” – With client-side encryption, you can check in the browser’s network tab that only encrypted bytes are uploaded.

When is server-side encryption sufficient?

Server-side encryption is not inherently bad. For non-critical content – such as transcribing a public podcast – it may be sufficient. But for:

  • Medical dictation and patient conversations
  • Client conversations in law firms
  • Board meetings and strategy discussions
  • Journalistic interviews with confidential sources
  • HR conversations and employee appraisals
  • Court hearings and witness statements

… client-side encryption is the only architecture that offers real protection. Because here the question is not whether a provider abuses your data – but that it technically cannot.

Conclusion

“Encrypted” is not the same as “protected.” The decisive difference lies in who controls the key. Server-side encryption protects hard drives. Client-side encryption protects your data – even from the provider itself. Anyone who works with confidential audio recordings should know this difference.

Server-Side vs. Client-Side Encryption: The Decisive Difference