Skip to content

Encrypt Files Before They Leave Your Device. Here's How.

Cloud providers scan everything you upload, so encrypt files with AES-256-GCM in your browser first and no server ever sees your key.

By THEYDIDNTASK

TL;DR

  • —You didn't ask for cloud providers to scan your files.
  • —Every time you upload a file to Google Drive, Dropbox, or OneDrive, you are trusting that provider with the contents of that file.
  • —Not just with storage—with the ability to read it.

You didn't ask for cloud providers to scan your files. They did it anyway.

—-

The Problem With Uploading Unencrypted Files

Every time you upload a file to Google Drive, Dropbox, or OneDrive, you are trusting that provider with the contents of that file. Not just with storage—with the ability to read it. And read it they do.

Cloud providers scan uploaded files for multiple purposes:

  • Content policy enforcement — automated scanning for CSAM, copyright violations, and terms-of-service infractions

  • AI training data harvesting — Google's terms allow using cloud content to improve models unless explicitly opted out

  • Ad targeting signals — metadata and content patterns feed advertising profiles

  • Government disclosure — all major providers comply with lawful access requests. Google received over 46,000 government requests for user data in the last reporting period alone

This is not speculation. Microsoft's own Digital Trust reports document thousands of law enforcement disclosures annually. Google's Transparency Report tells the same story. When your files sit unencrypted on someone else's server, someone else holds the keys.

Encrypting files before upload changes the equation. The provider sees ciphertext. Not your tax returns. Not your medical records. Not your private correspondence. Just noise.

—-

What Client-Side Encryption Actually Means

Client-side encryption means the encryption operation happens entirely on your device—in your browser—before a single byte leaves your machine. The cloud provider never sees:

  • The original plaintext

  • The encryption key

  • The password used for key derivation

Here is what happens under the hood with a properly implemented client-side encryption tool using the Web Crypto API:

  1. Key derivation — A user-provided password is run through PBKDF2 (Password-Based Key Derivation Function 2) with a high iteration count and a random salt. This turns a human-readable password into a strong cryptographic key.

  2. Random IV generation — A cryptographically random initialization vector is generated using crypto.getRandomValues(). The IV ensures that encrypting the same file twice produces different ciphertext.

  3. AES-256-GCM encryption — The file is encrypted using the Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode. GCM provides both confidentiality and authenticity verification, meaning you can detect if ciphertext has been tampered with.

  4. Authenticated tag — GCM produces an authentication tag that gets bundled with the ciphertext. Any modification to the encrypted data will cause decryption to fail with an integrity error.

The resulting encrypted file contains the salt, IV, ciphertext, and authentication tag—everything needed for decryption by someone with the password. Nothing else.

—-

When Client-Side Encryption Matters

Scenario 1: Sharing Sensitive Documents

You need to send a financial document, a legal filing, or a medical record to someone. Email attachments are not encrypted in transit end-to-end. Cloud sharing links give the provider access to the file. Encrypting the file client-side before sharing means the recipient is the only other person who can read it—provided you share the password through a separate channel.

Scenario 2: Backing Up Personal Data

Backup providers are notorious for scanning content. Encrypt your backups before they leave your device and the provider stores them as opaque blobs. No scan. No profile. No AI training.

Scenario 3: Journalists and Whistleblowers

The Reuters Institute documented over 40 journalist surveillance cases in 2025 alone. Encrypting documents before transmission is not optional for at-risk communications. It is operational security.

Scenario 4: Crossing Borders

U.S. Customs and Border Protection has the authority to search electronic devices at ports of entry. The Electronic Frontier Foundation recommends traveling with encrypted devices and encrypted cloud storage to limit what border agents can access. Encrypt files before you travel and the cloud provider cannot be compelled to decrypt them—they do not have the key.

—-

AES-256-GCM: Why It Is the Standard

The National Institute of Standards and Technology (NIST) published SP 800-38D in 2007, recommending GCM as an authenticated encryption mode. In 2026, AES-256-GCM remains the workhorse of modern encryption for good reason:

  • No known practical attacks against properly implemented AES-256

  • Authenticated encryption means tampering is detected

  • Hardware acceleration via AES-NI instructions makes it fast even in the browser

  • Broad browser support through the Web Crypto API

The File Encryptor on this site uses AES-256-GCM with PBKDF2 key derivation at 600,000 iterations. All operations execute in your browser. No file data, no password, no key material ever reaches a server.

—-

How to Encrypt Files Before Uploading

Using the File Encryptor

  1. Open the File Encryptor tool.

  2. Select the file you want to encrypt. No file size limit—it processes in your browser memory.

  3. Enter a strong password. Use a password manager. Do not reuse passwords.

  4. Click Encrypt File. The operation completes locally.

  5. Download the .enc file. This is your encrypted payload. Share it however you like—email, cloud storage, USB drive. Without the password, it is worthless to anyone else.

To decrypt:

  1. Open the same File Encryptor tool.

  2. Select the .enc file.

  3. Enter the same password.

  4. Click Decrypt. The original file is restored in your browser.

The password never leaves your device. There is no password recovery. If you lose the password, the data is gone. That is the price of security, and it is the correct design.

—-

Sharing Secrets Securely

Encrypting a file solves confidentiality. But sharing the password safely is a separate challenge. If you email the password alongside the encrypted file, you have accomplished nothing.

Use Separate Channels

Send the encrypted file through one channel (cloud link, email attachment) and the password through another (Signal, a phone call, an in-person conversation). This is the oldest rule in operational security for a reason.

Use Self-Destructing Messages

The Secure Share tool creates encrypted messages that can only be read once. The decryption key lives in the URL fragment—the part after the #—and is never sent to any server. When the recipient opens the link, the message decrypts in their browser. The link cannot be reused.

This is ideal for sharing passwords, API keys, or other secrets that should not persist in chat logs or email threads.

What Not to Do

  • Do not email the password. Email is plaintext at rest on most providers.

  • Do not use SMS. SMS is not encrypted and is trivial to intercept.

  • Do not reuse the same password across multiple shares. Compartmentalize.

—-

The Threat Model

Client-side encryption protects against:

  • Cloud provider content scanning

  • Cloud provider AI training on your data

  • Law enforcement requests directed at the cloud provider

  • Data breaches at the storage provider (they get ciphertext, not plaintext)

  • Unauthorized access by provider employees

Client-side encryption does NOT protect against:

  • Malware on your device that reads files before encryption

  • Keyloggers that capture your password

  • Physical access to your unlocked device

  • Compelled disclosure of the password (legal orders directed at you)

Encryption is a tool, not a magic wand. It changes who can read your data. It does not make data disappear. Threat model accordingly.

—-

Why Browser-Based Encryption Matters

You could install desktop encryption software like GnuPG, VeraCrypt, or age. Those are excellent tools. But a browser-based tool has distinct advantages:

  1. No installation required — works on any device with a modern browser

  2. Auditability — you can open the browser developer tools and inspect the network tab to verify nothing is being sent

  3. Zero persistence — no keys stored on disk, no cached plaintext

  4. Cross-platform — works on Windows, macOS, Linux, ChromeOS, and mobile

The trade-off is that you are trusting the website to serve legitimate JavaScript. For maximum assurance, you can save the tool page for offline use or audit the source code.

—-

Take Action

Encryption is not theoretical. It is the difference between a cloud provider reading your files and a cloud provider holding noise.

  • File Encryptor — encrypt any file with AES-256-GCM before uploading to cloud storage

  • Secure Share — share passwords and secrets with self-destructing, one-time-read links

Neither tool sends your data to a server. Both are free. Both work in your browser right now.

—-

You did not ask cloud providers to scan your files. You did not consent to your data training AI models. Encrypt before you upload. They cannot read what they cannot see.

—-

Related Reading:

Sources