How VitalSend handles your file.

Encryption

The file is encrypted in the browser before it leaves the device.

• A symmetric key is generated locally in the sender's browser.
• The file is encrypted with AES-GCM (via libsodium) chunk by chunk in a Web Worker, so the key material never touches the main thread.
• Only encrypted ciphertext is uploaded. VitalSend cannot read the uploaded file contents.

Key handling

The key is in the link. The server never sees it.

• The decryption key is placed in the URL fragment — the part after #. Browsers never transmit fragments to the server.
• Sending the link to a recipient is what transmits the key. VitalSend has no copy.
• Loss of the link means loss of the file. There is no key escrow and no reset path. This is intentional.

For deliveries where the link itself may leak, an optional password adds a second factor. The password is sent through a separate channel and must match before the recipient can decrypt.

Delivery

One download. Then the file is destroyed.

• A transfer is destroyed when a download completes successfully. A failed or partial download does not trigger destruction; the recipient can retry until one full download succeeds.
• An expiry timer destroys the transfer if no download ever completes.
• Destruction removes the encrypted blob and the metadata needed to fetch it. There is no archive, no backup of customer file content, and no operator workflow to undo destruction.

Account isolation

Sender accounts do not see transfer content or recipients.

• Recipients are anonymous and never log in.
• Senders may optionally hold an account for prepaid credits. Account identity is isolated from transfer activity by design — the account does not list, link, or expose past transfers.
• Billing and transfer paths are kept separate. A failed payment cannot leak transfer metadata into account state, and a transfer cannot mutate account credits outside the prepaid model.

Infrastructure

Operated in the EU.

• All application infrastructure runs on EU-based providers.
• Payments are processed by Mollie, an EU-based payment provider.
• VitalSend is operated by Agiletto AB, Gothenburg, Sweden, org. number 559108-1806.

Verification

The model is public so it can be checked.

• The client-side encryption code runs in the browser and is delivered unobfuscated. It can be inspected directly.
• The threat model is published — see the threat model.
• Vulnerability reports go through /.well-known/security.txt.