Encrypted Documents —
sensitive files the server can't read

When you select a file to upload, the Web Crypto API encrypts it in your browser with AES-256-GCM before any network request is made. The plaintext file is never sent over the wire — only ciphertext reaches the server. Even if you're on a compromised network, the intercepted upload is useless.

Files are split into 1MB chunks before encryption. Each chunk is encrypted with its own Initialization Vector (IV). Chunking enables reliable upload of large files over unstable connections (each chunk can be re-uploaded independently) and efficient streaming on download.

Even the file name and MIME type are encrypted before upload. The server stores only the encrypted blob and an item ID — it has no knowledge of what kind of file it is, what it contains, or what it's named. A database breach reveals literally nothing about your files.

When you open or download a file, ciphertext chunks are fetched from the server and decrypted in your browser. The plaintext file exists only in browser memory and is written to your disk only when you explicitly save it. The server never processes the decrypted content.

PDF, DOCX, XLSX, JPEG, PNG, ZIP, PEM, PFX, TXT — any file type is accepted. The encryption process is file-format agnostic; the encrypted blob is stored as-is. There are no format restrictions, no conversion, and no processing of your file contents.

Documents live in the same vault structure as passwords and notes. Store a certificate in the same folder as the server credentials it belongs to. Keep financial documents in a dedicated vault shared only with your accountant. Context-organized storage.

Documents in shared vaults are accessible to all vault members. Access is granted at the vault level — no per-file permission management needed. When a team member is removed from a vault, they lose access to all files in it immediately.