Security

How encryption works here

When you upload a file, your browser generates a random 256-bit key and encrypts the file — in 8 MiB chunks, using AES-256-GCM through the browser's built-in WebCrypto — before any byte is uploaded. There is no server-side encryption step, because the server never has anything it could read.

The key travels in the fragment of your link — the part after the # — which browsers do not send to servers. Our servers store only one-way hashes of the link's identifiers, so a stolen copy of our database could not locate, redeem, or decrypt anything.

A link can be redeemed once. Redemption is a single atomic database operation, so if two people click at the same moment, exactly one succeeds and the other is told the link was already used. The recipient then has one hour to finish the download, with retries allowed — a dropped connection does not burn the file.

What our servers store

• ·The encrypted file, under a random identifier, until it is downloaded or expires — then it is deleted, and the deletion is verified against storage before we record it.
• ·An encrypted metadata blob (filename, type, size) that we cannot decrypt. Filenames never exist on our servers in plaintext.
• ·Ciphertext sizes, timestamps, and each transfer's state: created, awaiting download, downloaded, deleted.
• ·Your account email and subscription status. Card details are held by Stripe, not by us.
• ·One-way hashes of the link token and its redemption proof — never the link itself.

We keep no backups of ciphertext. Versioning and replication are switched off on the storage that holds it, and objects are force-expired by storage lifecycle rules even if all of our code fails.

What we log and for how long

We do not claim “zero logs,” because that would not be true. The true sentence is: we keep minimal operational logs for 30 days, and they cannot contain your data.

Our logger accepts only an explicit allowlist of fields: event names, hashed link identifiers, account IDs, byte counts, timestamps, status codes, and the IP addresses we need for rate limiting and abuse response. A filename, a key, or a file's contents cannot appear in a log, because the server never possesses them in the first place.

Logs are deleted after 30 days. Access logging is disabled entirely for the storage that holds ciphertext.

The honest limits

When you use any web-based encryption tool, you trust the code the site serves that day. This is a limit of the entire category, ours included. We keep that surface tiny, dependency-free, and we publish how it works.

We cannot stop a recipient from sharing a file after they receive it. “One-time” applies to the link, not to what a person does with a file once they legitimately have it.

Anyone who obtains the complete link before it is redeemed can download the file. Treat a link with the same care as the file itself, and send it over a channel you trust. If a link is opened by someone other than your recipient, the download page tells the next visitor that the link was already used — and your dashboard shows when.

We can see traffic metadata — who sent how much, and when. We minimize it, we cannot connect it to file contents, and transfer records themselves are removed 30 days after a transfer ends.

Verify it yourself

The browser encryption client, the full threat model, and a claims-to-evidence matrix — every marketing sentence mapped to the control that enforces it — live in our repository's docs. The public repository link will be published here at launch.

Our storage configuration is checked automatically every day, and the result is published — pass or fail — on the trust page.