Sharing & sending
Share a folder
NewHand someone a whole folder with one public link. Anyone with the link can browse and download the files read-only, no account required, and it stays zero-knowledge, because the folder's decryption key rides in the part of the URL that never reaches our servers.
Sharing a whole folder
From a folder in your vault, choose Share to mint a public link that covers the whole folder’s contents, including its sub-folders. zcrypt generates a random folder-share key in your browser and re-wraps each file’s content-encryption key under it, so recipients can decrypt without ever knowing your passphrase.
Your vault has to be unlocked to create the link, because zcrypt needs your passphrase locally to recover each file’s key and re-wrap it. Files that can’t be re-wrapped are simply left out and the rest are still shared, the dialog tells you how many files were shared and how many were skipped.
Which files get skipped
A file is skipped if it was uploaded before per-file sharing existed (no key envelope to re-wrap) or if it lives inside a password-protected folder (its key is sealed under that folder’s password, not your vault passphrase). If none of a folder’s files can be shared, zcrypt tells you rather than creating an empty link.The key lives in the link, not on our servers
A folder link works exactly like a single-file share link, just for many files at once. The link has two parts that do very different jobs:
https://zcrypt.cloud/f/<token>#key=<folder-share-key>
└── sent to server └── never sentEverything after the # is the URL fragment. Browsers never transmit the fragment to the server, so the folder-share key stays in the address bar and is only readable by JavaScript on the page. Our servers store only the token and, per file, an opaque wrapped key they can never unwrap, never the folder key itself, and never any plaintext.
Treat the link like the folder's password
Anyone with the full link can open the folder, because the link carries the key. Send it over a channel you trust, and add a separate password (below) when the link might travel over something you don’t.Optional password protection
You can require a password on the link. It is hashed with bcrypt on the server and checked before anything about the folder’s contents is released. Until the correct password is supplied, the link won’t reveal the file listing at all, no names, no sizes, and no per-file keys. Only once the password checks out does the server hand back the list of files.
The password and the key are two separate locks
The password gates the listing on our side; the folder-share key in the fragment is what actually decrypts the files in the recipient’s browser. Someone needs both the full link and the password to open a protected folder.What the recipient sees
Recipients need no zcrypt account. Opening the link loads a public page that lists the folder’s files and lets them download any one file or grab them all. It is read-only: a folder link is for handing files out, not for collaboration, no one can add, rename, or delete anything through it.
- •If the link is password-protected, the page prompts for the password first and only then shows the file listing.
- •Each download fetches the encrypted chunks, decrypts them entirely in the recipient’s browser using the key from the fragment, and verifies the file’s SHA-256 before saving it. Plaintext is reassembled on their device, never on our servers.
- •If the link has expired or hit its download limit, the page explains that it is no longer available.
Expiry, limits, and revoking
Every folder link carries the same optional guardrails as a single-file share, all enforced on our side independently of the key in the fragment:
| Control | What it does |
|---|---|
| Expiry | Choose 1 hour, 24 hours, 7 days, 30 days, or never. After it lapses the link reports that it is no longer available. |
| Max downloads | Cap the number of accesses (for example 10, 50, 100, or unlimited). Once the count reaches the cap, the link stops working, see the note below on how it counts. |
| Revoke | Revoke any link at any time from the folder’s share dialog. Revocation is immediate: the server refuses all further requests for that token, so even someone holding the full link can no longer fetch the files. |
Folder links vs. shared vaults
A folder link and a shared vault solve different problems. Reach for the one that matches how much control you need:
| Folder link | Shared vault | |
|---|---|---|
| Who gets in | Anyone with the link (plus the password, if set) | Named members you invite, individually |
| Access level | Read-only download | Role-based, members can be given write access |
| Accounts | None needed for recipients | Members sign in to zcrypt |
| Best for | Handing a set of files to someone once | Ongoing collaboration on a shared set of files |
About the download counter
The cap counts files, not folder-opens
The download counter increments each time a recipient’s browser fetches an individual file’s metadata, the step right before that file’s chunks download. So one “Download all” of a five-file folder counts as five, not one. If you set a tight max downloads, size it against the number of files in the folder, not the number of people you expect to open the link.Where to go next
Other ways to get data to people and devices: