Encrypt a file with AES-256-GCM in the AES-256-GCM Encryptor. The key never leaves your browser, and the file is processed locally.
What cloud encryption does and does not cover
Cloud providers encrypt data at rest. That protects the physical disk and the storage layer, but the provider still holds the keys in most consumer products, and it can read the plaintext when serving a file to your account.
The risks that remain are practical: an account takeover, a stolen session cookie, a sync client copying a folder you forgot was shared, or a support tool that can access your data. Encrypting before upload changes the trust boundary: the cloud stores bytes it cannot read.
It does not protect a device that is already compromised, a weak password that guards the encrypted file, or a key stored next to the ciphertext. Encryption is one layer, not a complete security program.
Note: Encrypting a file does not hide its size, its upload time, or the fact that you uploaded something. It hides the content, not the metadata.
Use authenticated encryption
AES-256-GCM is a reasonable default for file encryption. It provides confidentiality and integrity: if a single byte of the ciphertext is modified, decryption fails instead of returning corrupted plaintext.
GCM needs a unique nonce for every encryption with the same key. A random 96-bit nonce is standard. Never reuse a nonce with the same key; with random nonces, the probability of a collision stays negligible for a normal number of files.
The key should come from a strong password through a slow key-derivation function such as PBKDF2, or from a random key file. AES-CBC without a separate MAC, custom XOR schemes, and "hidden" algorithms in a spreadsheet are not substitutes. The AES encryption production guide covers mode and key choices in more depth.
- Algorithm: AES-256-GCM with a 96-bit random nonce.
- Integrity: the authentication tag must be checked before using the plaintext.
- Key derivation: PBKDF2 with a high iteration count, or a random 256-bit key.
- Nonce storage: stored with the ciphertext; it is not secret, but it must be unique.
Encrypt before the file leaves your device
- Open the AES-256-GCM Encryptor and choose file mode.
- Select the file. It is read locally and never uploaded.
- Use a strong passphrase, or generate one and store it in a password manager.
- Encrypt and download the encrypted file. The original stays untouched.
- Export the key file if the tool offers it, and store it somewhere separate from the ciphertext.
- Upload only the encrypted file to cloud storage.
- Download it once and decrypt it to confirm the backup works before deleting the local original.
Warning: If you lose the passphrase and the key file, the data is gone. There is no recovery service for a file you encrypted locally.
Key management is the hard part
The encryption is usually the easy step. The failure mode is key management: a key saved in the same cloud folder, a passphrase reused from another account, or a single copy on the laptop that dies. For secrets that live in a repository, encrypting .env files before commit applies the same rule.
Keep at least two copies of the key in separate places, such as a password manager and an offline backup. Do not upload the key to the same provider as the ciphertext. If the cloud account is compromised, the attacker should get a file they cannot open.
For a team, decide who can decrypt and how keys are rotated before the first upload. Rotating a key means decrypting and re-encrypting every file that used it; plan for that cost.
- Never store the key in the same bucket or folder as the encrypted file.
- Use a unique passphrase; do not reuse an account password.
- Keep an offline copy of the key file.
- Record which key belongs to which file if you rotate keys.
- Test decryption on a second device before relying on the backup.
Filenames and sync clients leak too
A file named passport-scan.pdf tells the provider and anyone with access what the encrypted blob contains. Rename it to something neutral before upload, and keep the mapping in your own notes.
Sync clients can upload automatically as soon as a file lands in a watched folder. If you use Google Drive, Dropbox, or iCloud Drive, encrypt the file before moving it into that folder. For photos, turn off automatic upload for sensitive albums or encrypt first and upload the result.
Note: Cloud version history and thumbnails may retain earlier copies. If a file was uploaded in plaintext once, deleting it now may not remove every version.
Where this workflow stops
A browser encrypts in memory, so very large files are limited by the device's RAM. Zip a folder first, or split it into smaller archives, then encrypt each archive.
Encrypted files cannot be searched, previewed, or edited collaboratively in the cloud. If a team needs to work on the document, encrypt it only for storage and decrypt it into a controlled local environment for editing.
Encryption also does not remove the need for backups. Keep the encrypted file and the key backed up separately, and test the restore path.
FAQ
Q.Is provider-side cloud encryption not enough?
A.It protects the storage infrastructure, but in most consumer products the provider holds the keys and can access the plaintext. Encrypting before upload means the provider only ever sees ciphertext. The trade-off is that you become responsible for the key.
Q.What happens if I lose the key?
A.The file cannot be decrypted. There is no recovery path when you encrypt locally and keep the key yourself. Store at least two copies in separate places, and test one of them before you need it.
Q.Can I encrypt photos before iCloud or Google Photos?
A.Yes, but the encrypted file will not preview as a photo, and automatic upload may copy it before you finish. Encrypt first, upload the encrypted file, and keep the key out of the photo library. For sensitive albums, disable automatic upload.
Q.Does renaming the encrypted file break it?
A.No. The ciphertext contains what it needs to decrypt, provided you keep the key and the nonce metadata intact. The filename is not part of the cryptographic payload, but it can still leak information, so choose a neutral name.
References
- NIST SP 800-38D – Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM): https://csrc.nist.gov/pubs/sp/800/38/d/final
- OWASP – Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
- W3C – Web Cryptography API: https://www.w3.org/TR/WebCryptoAPI/
- RFC 8018 – PKCS #5: Password-Based Cryptography Specification Version 2.1: https://www.rfc-editor.org/rfc/rfc8018
Encrypt a file before upload
AES-256-GCM in your browser. Your file and key never leave your device.
Encrypt first, upload second
The cloud is a good place to store ciphertext and a poor place to trust with plaintext you cannot afford to expose. Encrypt locally, keep the key somewhere else, and verify that you can decrypt before you rely on the backup.
Encrypt a file with AES-256-GCM in the AES-256-GCM Encryptor. The key and the file stay in your browser.
Related Articles
Encrypt .env Files Before Commit
Committing a plaintext .env leaks every secret in your repository. If a copy must live in git, encrypt it first - here is the safe workflow.
AES-256-GCM Encryption: A Developer's Guide
Encrypt and decrypt files locally in your browser with AES-256-GCM - no upload, no account. Code examples, plus AES-256-GCM vs AES-256-CBC vs ChaCha20.
Building a Complete Password Encryption System
From user password to encrypted data storage. A complete solution for secure applications.
Zero-Knowledge Architecture: Protecting Data
An in-depth look at zero-knowledge architecture and why ZeyroVault Tools cannot see your data.
Encrypt Text Before Sending to ChatGPT
Anything you paste into an AI assistant goes to a service that may log or train on it. Encrypting first keeps source code, customer data, and plans unreadable to everyone but you.