rclone crypt vs Cryptomator: Do You Actually Need Both for Cloud Encryption?

rclone crypt does what you want — but it is not a Cryptomator replacement

The short answer: yes, rclone crypt works exactly the way the question describes. Mount a crypt-wrapped remote, and files appear as plain data locally while the cloud stores only ciphertext. Write a file to the mount and rclone encrypts it before it ever leaves your machine. List the same bucket or Drive folder in a browser and you see scrambled filenames and unreadable content. That part of the setup is solid and works well.

The problem comes one step later.

What rclone crypt actually puts on the remote

rclone crypt does not produce .c9r files. It has its own container format: file contents are encrypted with a random nonce per file, and filenames are replaced with base32-encoded ciphertext strings. The format is open — rclone is open source and the scheme is documented — but only rclone can decrypt it. Open that same Google Drive folder in a Cryptomator desktop app, on an iPhone running the Cryptomator mobile client, or in any other Cryptomator-compatible tool, and the files are completely unreadable.

If Cryptomator was part of your stack specifically because other devices read the same vault, switching to rclone crypt breaks those devices silently. The cloud folder still exists and still looks encrypted — it just speaks a different language now.

How Cryptomator’s format differs

Cryptomator encrypts each file individually and wraps it in a documented container with the .c9r extension. Directory names and filenames get their own encryption pass. The whole spec is publicly available, which is why independent clients — desktop, mobile, and third-party integrations — can all open the same vault without needing to coordinate.

The encryption uses AES-256 for file content (AES-CTR mode) and AES-SIV for filenames, and the design has gone through published independent security audits. The vault boundary is explicit: one root directory, everything inside is ciphertext, everything outside is plaintext once mounted.

rclone crypt’s encryption model

rclone crypt uses XSalsa20-Poly1305 for file content — a stream cipher with an authentication tag, which is a well-regarded construction. Each file gets a random 24-byte nonce, so two identical files produce different ciphertext on the remote. That prevents an attacker from learning anything about file content by comparing blobs. Filename encryption is optional; when enabled, filenames are encrypted with AES-CTR and a separate key.

The scheme is solid for practical use. What it lacks is a standalone, audited security specification that an external party can point to. Cryptomator has published audit reports; rclone crypt does not. For most personal and small-business use cases that distinction doesn’t matter. For regulated environments or compliance reviews, it might.

Mobile access and GUI clients

Cryptomator ships native apps for iOS and Android. That means a vault stored on Google Drive or Dropbox can be opened on a phone with no extra setup — the app handles the mount and decryption. rclone crypt has no official mobile client. There are community efforts and workarounds, but nothing that matches Cryptomator’s out-of-the-box phone experience.

Cryptomator also has a desktop GUI, which matters for users who aren’t comfortable with the terminal. rclone is CLI-first. That’s a feature for some people and a barrier for others.

Using rclone with a Cryptomator vault

There is a middle path. rclone includes a dedicated Cryptomator backend — separate from rclone crypt — that can mount and sync existing Cryptomator vaults. This means you can keep the vault in Cryptomator’s .c9r format so mobile apps and desktop clients still work, while also driving sync and automation tasks through rclone scripts. You get the cross-platform compatibility of Cryptomator’s format without giving up rclone’s scripting flexibility.

The setup involves pointing rclone’s Cryptomator backend at the vault’s master key file and the remote where the vault lives. It is worth reading the rclone docs on this backend specifically, since the configuration is different from rclone crypt.

When each one makes sense

• rclone crypt: all devices that need access run rclone, mobile access is not required, you want to automate sync with scripts or cron jobs, and you prefer keeping the toolchain minimal. One tool, one config, done.
• Cryptomator: you need phone or tablet access to the same vault, you are sharing files with people who are not comfortable with command-line tools, or you need a published security audit for compliance. Also the right call if you already have a Cryptomator vault with existing data — migrating means re-encrypting everything.
• rclone’s Cryptomator backend: you want Cryptomator’s portable vault format but also want rclone’s automation capabilities. A reasonable hybrid.

Neither tool is strictly better. They overlap on the core feature — transparent client-side encryption for cloud storage — but diverge on format compatibility, mobile support, and ecosystem. The format incompatibility is the detail most people miss when they first discover rclone crypt.