The 40-second answer
To keep photos private from your cloud provider, the file has to be encrypted on your device before it leaves, with a key the provider never holds. You can bolt a tool like Cryptomator onto Google Photos or Drive and do it by hand, or use storage that encrypts client-side automatically so every upload is opaque to the server from the first byte. The second path has fewer moving parts and is much harder to get wrong.
"Encrypted in the cloud" is not the same as private
Google Photos and iCloud both encrypt your photos in transit and at rest. Looks like the box is ticked. It isn't. The provider still holds the keys, which means the photos are readable on their side: for AI features, content scanning, advertising signals, lawful-access requests, and anyone who breaches the servers.
Google designed it that way on purpose. Face grouping and object recognition in Google Photos run after upload, on Google's servers, against the plaintext image. That only works because Google can read your library, and no setting removes that access. Apple does better here. Its Advanced Data Protection turns iCloud Photos into genuine end-to-end encryption. But it ships off by default, you have to dig into Settings to switch it on, and Apple withdrew it for new users in the United Kingdom in early 2025 after a government order demanded backdoor access. Encryption you have to find and enable is encryption most people never get.
The manual route is real, and fragile
The standard advice is to encrypt photos yourself before they touch the cloud. The tools are good. Cryptomator creates a "vault" inside your Dropbox or Google Drive folder, encrypts each file with AES-256 on your device, scrambles the filenames too, and is open source and free on desktop. VeraCrypt builds encrypted container volumes you mount as a virtual drive: strong, but it's a disk-encryption tool, not a photo-sync one. 7-Zip can spit out a password-protected AES-256 archive, fine for a one-off batch and miserable as a daily habit.
The crypto is sound. The workflow is where it breaks. You're running encryption as a separate layer on top of a service that was never built for it. A photo you shoot on your phone doesn't land in the vault on its own. Google Photos keeps its own plaintext copy unless you've disabled backup and rerouted everything through the encrypted folder by hand. Mount the vault, copy files in, wait for sync, unmount. Skip a step and the original sits in the provider's plaintext store anyway. You've added friction without closing the hole, because the convenient default path still walks straight around your encryption.
It also barely survives contact with a phone. Stapling Cryptomator onto mobile photo backup is clumsy, and the entire point of cloud photos is that your camera roll syncs while you think about nothing. The day privacy demands a decision on every shot is the day you stop making it.
The better route: encryption as the default, not a bolt-on
The cleaner answer is storage where client-side encryption isn't a layer you bolt on; it's the only way the system runs. With zero-knowledge architecture, encryption happens in the client before a single byte goes up, and the server is structurally incapable of reading your files. There's no plaintext copy anywhere because there's no plaintext path to begin with.
Here's the mechanism in beebeeb. You pick a passphrase; it's stretched into a key with Argon2id (256 MB memory, 4 iterations) entirely on your device. Every file gets a random per-file key and is encrypted with AES-256-GCM. Sharing is keyed with X25519. Login uses OPAQUE, so your password never reaches the server either. Keys are zeroized from memory after use. Because your passphrase and file keys never leave the device, we can't read your photos, can't hand them to anyone, and can't recover them if you lose your BIP39 recovery phrase. That last line is the honest cost of real zero-knowledge, and we'd rather say it than paper over it.
What that buys you day to day: no vault to mount, no folder to remember to drag files into. You upload a photo and it's already encrypted, the same as any other file. No second tool, no second password to lose, no plaintext escape hatch you forgot to seal.
What works today, and what's coming
Being straight about the state of the product matters more than a tidy pitch. Right now you can upload and manage photos through the beebeeb web app and the CLI, share them with expiring or passphrase-protected links you can revoke, keep prior versions with retention you configure, and lock the account with TOTP 2FA or passkeys. Every tier is zero-knowledge, the free one included.
What isn't here yet: native mobile apps with automatic camera-roll backup. That's the piece that finally makes encrypted photo storage feel like Google Photos instead of homework, and it's coming. Importing an existing library straight from Google Drive or Dropbox is coming too. Until then the web app and CLI are the path, and they encrypt before upload exactly the way the finished mobile app will.
So which should you do
If you're staying on Google Photos or iCloud and just want a private corner of it, Cryptomator is a legitimate, free, open-source way to encrypt a subset of photos before they sync. Accept that it's a manual layer, and that your camera roll's default backup keeps running in plaintext right next to it.
If you'd rather not babysit encryption as a side process, and want every photo encrypted on the device by default with no plaintext copy anywhere, client-side-encrypted storage is the structurally simpler answer. To be fair on cost: iCloud+ is cheaper at the bottom, at $0.99/month for 50 GB and $2.99/month for 200 GB, and Proton matches us on encryption and open-source clients. We don't claim to beat everyone on price. We claim the encryption is on by default, on every plan, with nothing to opt into and forget.
Your photos get encrypted on your device whether you pay or not. That's the part that was never meant to be a premium feature.