Every file you share online passes through infrastructure you don't control. Google Drive. Dropbox. iCloud. Gmail. Telegram. WhatsApp. The platform might promise encryption. They might be telling the truth. But you're still trusting them to implement it correctly, not to hold a copy of your keys, not to comply with a secret legal order, and not to suffer a breach that exposes stored files.

That's a lot of trust for a file that might contain medical records, legal documents, financial statements, personal photos, or business information.

The alternative is simple: encrypt the file yourself, on your device, before it goes anywhere. Then it doesn't matter who stores it or who intercepts it — without the password, it's meaningless data.

Why Platform Encryption Isn't the Same Thing

Most cloud platforms encrypt your files "at rest" — meaning they're encrypted when sitting on their servers. This protects against a physical server theft or a lower-level attacker. What it doesn't protect against is the platform itself.

If Google, Dropbox, or iCloud holds the encryption keys (which they typically do for standard accounts), they can access your files. They can hand them to governments. They can be compelled to do so quietly, without notifying you, in many jurisdictions. And if their systems are breached in a way that exposes keys alongside data — your files are gone.

End-to-end encryption, where offered, is better — but even then, you're trusting the platform's implementation. You can't audit it. You can't verify the keys are handled correctly. You're taking their word for it.

The legal reality: In the UK, the Investigatory Powers Act can compel companies to hand over data and gag them from telling you. In the US, National Security Letters work similarly. In the EU, Article 6 of the GDPR has exceptions for national security. Client-side encryption is the only defence that survives all of these — because the platform simply never has your plaintext to hand over.

How Client-Side File Encryption Works

Client-side encryption means the encryption happens on your device before the file goes anywhere. The server, the platform, the recipient's email provider — none of them ever see the original file. They only ever see encrypted ciphertext.

The process is straightforward:

1
Key Derivation Your password is run through PBKDF2 — a function specifically designed to make brute-force attacks expensive. 600,000 rounds of SHA-256 hashing, combined with a random salt, produces a 256-bit encryption key that can't be feasibly derived from the password without doing all that work.
2
Encryption AES-256-GCM encrypts the file contents. The original filename is encrypted too — hidden inside the output. A random 12-byte initialisation vector ensures that encrypting the same file twice produces different ciphertext.
3
Authentication GCM mode appends a 16-byte authentication tag to the output. If anyone tampers with the encrypted file — even changing a single byte — decryption fails and an error is thrown. There's no way to modify the ciphertext without detection.
4
Output The result is a .venc file. Share it over any channel — email, Telegram, WhatsApp, Google Drive, a USB stick. Without the password, it's indistinguishable from random bytes.

The Cryptographic Specs

CIPHER
AES-256-GCM
256-bit key, authenticated encryption, GCM mode. Same cipher protecting classified military communications.
KEY DERIVATION
PBKDF2-SHA256
600,000 iterations. NIST recommended minimum is 600k as of 2023. Makes brute-force extremely expensive.
SALT
16 bytes random
Generated fresh for every encryption. Prevents rainbow table attacks and ensures unique keys per file.
IV
12 bytes random
Fresh per encryption. Encrypting the same file twice produces completely different ciphertext.

What About the Password?

The encryption is only as strong as the password. A weak password can be brute-forced even if the encryption algorithm is perfect. A few things that actually matter:

What This Protects You From

When a file is encrypted before sharing:

What it doesn't protect: the fact that you sent a file to someone, or the metadata about the transfer (file size, timestamp, recipient). For those concerns, combine file encryption with an encrypted communication channel.

🔑 Encrypt Your Files Now

AES-256-GCM. Browser-only. No upload, no account, no server. Any file type, up to 500 MB.

Open File Encryptor →

The Recipient's Side

Decryption is just the reverse. The recipient drops the .venc file into the same tool, enters the password, and the original file is restored — with the original filename, exactly as it was. No software to install, no account to create. Just a browser.

The authentication tag is verified before decryption completes, so if the file has been tampered with or the password is wrong, they'll see an error rather than corrupted output. There's no way to silently produce a wrong result.

The Bottom Line

You don't need technical knowledge to encrypt a file. You don't need to install anything. You need a browser, a strong password, and about ten seconds. After that, the file can travel anywhere — email, cloud storage, messaging app, it doesn't matter — and it remains private.

The question isn't whether you have something to hide. It's whether you want to hand every file you send to whoever might be watching. Client-side encryption means you don't have to.