Send a file that self-destructs after it's downloaded

How file sharing works here

1. Pick a file, up to 25 MB. Your browser encrypts it before anything leaves your machine — AES-256-GCM through the browser's native Web Crypto API, no third-party crypto library. The 256-bit key comes from crypto.getRandomValues, generated on your device.
2. Only ciphertext is uploaded. The server stores it under a random 32-character hex name and never receives the key.
3. You share one link. The key sits after the # in the URL. Browsers do not transmit that fragment in HTTP requests, so it cannot reach our server, our logs, or a Referer header.
4. The recipient decrypts locally. Their browser fetches the ciphertext, decrypts it on their own machine, and restores the original filename. When the download limit or the expiry is reached, the file is gone.

Your filename tells the whole story — so we encrypt it too

A filename is not a harmless label. Often it is the message.

Read these and notice how little of the content you still need: salary_review_j_smith.xlsx. passport_scan.jpg. biopsy_results_2026.pdf. redundancy_list_final.docx. Each one names a person, a document, or a decision before a single byte is decrypted. A service that encrypts the contents but stores the filename in the clear has told the story anyway — to its own database, to its backups, to anyone who ever reads either.

So the filename and the MIME type are encrypted in your browser as a separate ciphertext, alongside the encrypted bytes. On our server, the file exists only under a random 32-character hex name. We are not the only service that encrypts filenames, and we do not claim to be. Our claim is narrower: we cannot read yours, because it never reaches us in readable form.

Stored outside the web root, counted by the server

The encrypted bytes do not sit in the public web directory. There is no URL that fetches them directly. Every download passes through a server-side script that checks the expiry and the download counter first, and streams the ciphertext only if both allow it.

That distinction matters. A limit enforced in the page can be bypassed by anyone who skips the page. This one is enforced where the bytes live, so the download counter cannot be sidestepped by fetching a URL directly — no such URL exists. Identifiers are 128 bits from a cryptographically secure generator, never a weak PRNG, and the expiry sweep runs from cron every five minutes, whether or not anyone visits.

What we don't do

• ACCOUNTS None. No registration, no email address, no cookies at all, no analytics, no third-party scripts.
• UPSELL The 25 MB limit is the limit. The service is free, and there is no paid tier waiting behind it.
• SCANNING We cannot scan the contents of your files. We hold ciphertext, and the key never reaches us.
• ACCESS LOGS Access logging is switched off for this site in the web server configuration. No record exists of who downloaded which file. One caveat, stated plainly: the error log still exists and can capture an IP address when a request fails.

When to use this — and when not to

Use this for secrets that fit in 25 MB: a contract, a scanned identity document, a keyfile, a spreadsheet that names people. One sensitive file, one link, a counted number of downloads, then nothing. That is the case this design serves.

Do not use it for a 4 GB video. It will not fit, and we would rather say so than stretch the truth. For large media, use an ordinary transfer service and accept the trade-off that comes with it. For the file whose name alone could hurt someone, come back here. And if what you need to share is a conversation rather than a file, open a disposable chat room instead.