How to send someone a file without it sitting on a server

An email attachment

Mail is encrypted in transit only between one server and the next. The Received: lines at the top of a message are the record of that: each hop is written by the machine that took delivery, and a hop marked with ESMTPS was encrypted on that leg alone. Every server in the chain held the whole message in a form it could read. MAILBOX will draw that chain out of a message you already have.

The larger problem is not the wire, it is the copies. An attachment makes one in your Sent folder, one in their inbox, and one in each provider's storage and backups. You control exactly one of the four, and deleting it changes nothing about the rest.

A link to cloud storage

Two things are going on. The file is with the provider in a form they can read (that is what makes previews, search and virus scanning work), so the plaintext is theirs for as long as they keep it.

The link is the other half, and a share link is a bearer token: possession is authorisation, and the service cannot tell your recipient from anyone else holding the same string. "Anyone with the link" survives forwarding and survives being pasted into a channel the whole team reads. It is the right answer for a file that may as well be public. It is not a private channel.

An encrypted archive, and what a zip password actually is

Zip puts two different schemes behind the same "password" box, and which one you got decides whether the file is protected at all.

The legacy scheme, usually labelled ZipCrypto or "compatible", is broken and has been for decades, and the reasons are visible in the bytes. The entry still declares compression method 8 and sets bit 0 of the general purpose flag; twelve bytes of encryption header are prepended to the data; the file name sits in the header in plain text; and the CRC-32 of the plaintext is stored in the clear. In a test archive built for this page that field read 6e6b2e69, exactly the CRC-32 of the original file. A known 32-bit fingerprint of the thing you are hiding is what lets a guessing attack discard nearly every wrong password without decrypting anything.

The modern scheme is WinZip AES, and the same test looks different. The compression method field becomes 99, and an extra field with header ID 0x9901 carries the real method and a strength byte, 3 meaning AES-256. The CRC field is zeroed rather than filled in. The overhead per entry is 28 bytes: a 16-byte salt, a 2-byte password verification value and a 10-byte authentication code. That construction is sound.

Two limits survive either way. File names, sizes and folder structure stay readable without the password; only contents are encrypted. And the password is stretched with PBKDF2 at 1,000 iterations, the format's fixed figure, where CAPSULE uses 600,000 rounds for the same job. Then it still has to reach the recipient, which is the problem you started with.

Encrypting to someone's public key

This is the shape that removes the shared secret. The recipient generates a key pair and hands you the public half; anything encrypted to it can be opened only by whoever holds the private half. Nothing secret travels in either direction, so there is no key to intercept and no password to invent.

KEYRING does this in the age format, written out on the page rather than pulled from a library. A 128-bit file key is generated, wrapped to each recipient through an ephemeral X25519 exchange; the header is authenticated with HMAC-SHA-256; the body goes in 64 KiB chunks under ChaCha20-Poly1305, counted so a truncated file is refused rather than quietly accepted. Recipients look like age1..., private keys like AGE-SECRET-KEY-1..., and because it is the real format a file made here opens with the age program anywhere.

The private key is shown once and never kept, because a secret key in browser storage is readable by anything that gets script onto the page, which also means losing it loses the files. CIPHER does the same for a block of text you paste into a message, using ECDH on P-256 with AES-256-GCM.

Straight from one browser to the other

The other way to avoid a stored copy is not to make one. VAULT opens a WebRTC data channel between two browsers and streams the file across it in 16 KiB chunks, encrypted with AES-256-GCM before it is chunked, so the bytes on the wire are ciphertext whatever the transport does.

A signalling step is still unavoidable: the two ends have to exchange connection descriptions before a direct path exists. VAULT makes you do it by hand, so no signalling server holds a record of who connected to whom, and the key is shown separately from the connection code and meant to travel by a different route. A public STUN server, stun.l.google.com:19302, helps the two ends find each other and learns only that two addresses wish to connect.

The limits are structural. Both tabs must stay open, since nothing is stored for later pickup, and there is no relay fallback, so behind symmetric NAT or a locked-down corporate network the connection fails outright rather than quietly routing the file through somebody else's server.

The weak point they all share

Every scheme built on a shared secret (the zip password, CAPSULE's passphrase, VAULT's key) fails the same way: the secret goes in the same email as the file. The container is then exactly as private as the channel, and you have added work rather than protection. Use a different channel, and ideally a different kind of channel: a phone call, an app the file did not travel through, an agreement made in person. The public key approach sidesteps this entirely, because there is no shared secret to move.

What to use

KEYRING when the recipient can produce an age public key, because it is the only option with no secret in transit. CAPSULE when they cannot: it seals files into a single HTML page that decrypts itself in any browser, offline, with nothing to install, capped around 40 MB because the whole thing is built and opened in memory. VAULT for something large when you are both at a keyboard at once. LOCKBOX for finished client work: the same encrypted container, with watermarked previews and a manifest listing the SHA-256 of every file, so the client can see what they are getting and still get nothing usable until you send the key.

What none of this covers

All of it protects contents, not the fact of the transfer. Who you sent something to, when, and roughly how large it was survives every option here.

None of it helps if either machine is already compromised: a keylogger reads the passphrase, and malware reads the file once it is decrypted. Nor does encryption say anything about who you are talking to: take a public key from an email that was not really from them and you have encrypted the file neatly to the wrong person. And a self-decrypting capsule is a file that runs script, which is what a careful recipient has been told to avoid opening. Tell them it is coming.

Two cases this does not cover

There is no network at all. A machine deliberately kept off every network cannot receive an encrypted file by any of the routes above, and a USB stick is the thing such a machine exists to refuse. AIRGAP moves the file optically instead: it plays the bytes as a run of QR frames on one screen, and a camera on the other machine reads them back. Slow, and it crosses a gap nothing else does.

You are sending the same document to several people and it matters which copy leaks. Encryption does not help here at all: everyone you sent it to can open it, which was the point. CANARY weaves an invisible per-recipient mark through the text, repeated often enough that a quoted paragraph still carries it. Read its limits before relying on it: zero-width characters do not survive a screenshot, OCR or retyping, some clients strip them, and what it identifies is a copy rather than who pressed send.