Every chunk on disk is already encrypted at rest. End-to-end goes further: flip it on for a folder and the browser encrypts before upload, so even the server admin sees only ciphertext and opaque names.
A folder can carry a client-side encryption policy. When the policy is active, new uploads into that folder are encrypted in the browser if the user has unlocked the encryption vault. Child folders can inherit the policy, so a protected tree stays protected during normal drag-and-drop work.
Client-side encryption is unlocked with an encryption password or a 24-word recovery phrase. The password is separate from the account password and is not sent to the server, which means the server cannot reset access to encrypted files if both recovery paths are lost.
Encrypted uploads use a Cotton container blob with a generated opaque server-side file name. The visible filename and content type are stored as encrypted display metadata, so the UI can recover the real name after unlock without exposing it as plain server metadata.
The current browser E2E path is Blob-based and guarded at 512 MB per encrypted file. That limit is intentionally visible because it prevents a browser tab from turning client-side encryption into a memory problem before the streaming pipeline replaces it.
After the browser encrypts an E2E file, Cotton still stores that ciphertext through the normal content-addressed, compressed, encrypted storage pipeline. The two layers solve different problems: E2E protects selected content from server-side plaintext handling, while storage encryption protects persisted chunks and backup artifacts.
E2E should be marketed as selected client-side encrypted folders/files, not as a blanket claim that every feature is browser-only encrypted. Shares, previews, search behavior, and metadata visibility should be documented feature by feature as the E2E surface expands.
The E2E surface has real moving parts: folder policy metadata, browser vault unlock, encrypted display metadata, opaque server-side file names, browser-side decrypt on download, and a visible 512 MB guard for the current Blob path.
Cotton gives users a focused place for the files that should be encrypted before the server ever handles plaintext, without pretending that every product feature already has the same E2E semantics.
Client-side encryption currently fits selected folders and guarded file sizes. Lost vault credentials can make encrypted content unrecoverable, and features around previews, shares, and search need explicit E2E behavior rather than vague promises.
The upload path stores an opaque generated server-side name and encrypted display metadata for the visible name/content type. The client can show the real values after the vault is unlocked.
The current browser E2E implementation uses a Blob-based encrypt/decrypt pipeline. The guard avoids browser memory pressure until client-side streaming encryption replaces that path.
Do not plan on that. Client-side encryption is useful because the server does not hold the plaintext path; losing vault material can make encrypted content unrecoverable.