how to

How to Encrypt Files Before Uploading to Any Cloud

· 3 min read encryptionsecuritycryptomatorcloud-storage

Standard cloud storage encrypts data in transit and at rest, but the provider holds the keys and can scan, index, or hand over your content. Client-side encryption flips this: you encrypt on your device before upload, so the provider stores opaque blobs it cannot open. This guide covers three practical tools for different needs — ongoing transparent vaults, single-file sends, and scripted bulk backups.

What you need

  • Cryptomator (free, open source) for everyday vault-style protection
  • age or 7-Zip for one-off encrypted archives
  • rclone with crypt remote for automated encrypted backups
  • A password manager to store generated keys and passphrases

Step by step

  1. Pick the right tool. Continuous access to many files: Cryptomator vault mounted as a virtual drive. Sending one document to someone: age or an AES-256 7z archive. Nightly backups to B2 or S3: rclone crypt. Do not mix approaches for the same data.
  2. Install Cryptomator and create a vault inside your sync folder (Dropbox, OneDrive, iCloud). Set a strong passphrase — twelve words minimum — and save the recovery key in your password manager, not on the same cloud.
  3. Mount the vault and work normally: anything saved to the virtual drive appears in the sync folder as ciphertext with scrambled names. Close the vault before stepping away; the mount is the lock.
  4. For single files, generate a key with age-keygen, then encrypt with age -r <recipient-public-key> -o report.pdf.age report.pdf. The recipient decrypts with their private key — nothing secret ever travels by email.
  5. Alternatively use 7-Zip: add files to an archive, choose zip or 7z format, set encryption to AES-256, enable Encrypt file names, and use a long generated passphrase delivered out-of-band.
  6. Automate bulk backups with rclone: configure a crypt remote wrapping your storage remote (rclone config), then point your backup job at cryptremote:folder. Files encrypt locally during transfer; the provider sees only noise.
  7. Test decryption on a second device before committing. Download three files raw (not through the tool) to confirm they are unreadable ciphertext, then decrypt them properly through the tool.
  8. Document your scheme in one line per dataset: which tool, where keys live, who can recover. Future-you during an emergency is the main audience.

Common mistakes

  • Losing the key by storing it only in the same synced folder it protects. Zero-knowledge means nobody can reset it — no vendor, no support ticket.
  • Encrypting files but leaving originals in an unencrypted temp folder that also gets synced. Check what your editor leaves behind (autorecover, swap files).
  • Using short passphrases like Summer2026!; offline brute force against a leaked blob is unlimited-speed, so length beats complexity.

Related guides

Encryption slots directly into step five of [[setup-3-2-1-backup-rule]], where it protects your offsite copy. Encrypted single-file delivery pairs with the workflow in [[share-large-files-securely]], and if you are moving providers, [[migrate-between-cloud-providers]] shows how to layer crypt remotes onto an existing rclone setup.

← All guides