Share Files Temporarily Online: Self-Destructing Links

A self-destructing file link is a URL that stops working after a set time or a set number of downloads. Once the link expires, the file is deleted from the server and can't be recovered. HexaTransfer defaults to 14 days, with an option to delete manually at any time. Firefox Send used to set one-download expiry (it shut down in 2020). Snapchat-style one-and-done delivery is the strictest form. The point is simple: files that don't need to exist forever shouldn't.

How self-destruct actually works server-side

When you upload a file, the service stores it with a record like:

file_id: abc123
encrypted_blob: s3://bucket/abc123.bin
created_at: 2026-04-17T10:30:00Z
expires_at: 2026-05-01T10:30:00Z
max_downloads: null
download_count: 0

A scheduled job (often a cron-style worker or an object-lifecycle policy in S3/R2) deletes any blob past expires_at. When someone hits the download endpoint, the service decrements max_downloads or increments download_count and, if limits are breached, either refuses service or triggers deletion. Object storage lifecycle rules (AWS S3, Cloudflare R2, Backblaze B2) can automate this without custom code.

Three expiry strategies

Time-based: link dies after N days. Simple, predictable. Good for "I might send this again tomorrow" scenarios. HexaTransfer's default.

Count-based: link dies after N downloads. Useful when you know exactly how many recipients exist. Blocks over-sharing — if one person forwards it, the next person can't download after the cap.

One-time: single download, then the blob is immediately purged. Strongest. Appropriate for passwords, tokens, keys, or pre-release material. Tools like PrivateBin (for text) and Tresorit Send offer this.

Combine them: "7-day expiry or 3 downloads, whichever comes first" is a pragmatic default for sensitive material.

When temporary sharing actually helps

• Sending a signed contract back and forth during negotiation — no need for the draft to live on Google Drive after closing.
• Delivering credentials or API keys to a new team member without them hanging around in Slack history.
• Sharing a pre-release product photo under NDA — the link dies before the embargo date passes.
• Handing over a medical scan to a specialist for a second opinion, with no long-term copy needed.
• Gifting a licence file bought on someone else's behalf.

If the file doesn't need to exist a week later, a permanent Drive folder is just accumulating liability.

When it doesn't help

Self-destructing links don't protect against:

• The recipient downloading and saving the file. Once it's on their disk, your expiry means nothing.
• Screenshots or re-uploads. Digital content is trivially copied.
• Legal discovery. If you're under a litigation hold, "the link expired" is not a defence.
• The service itself logging metadata (filename, size, IP, timestamps) indefinitely.

Temporary sharing reduces the blast radius of accidental long-tail exposure (forgotten links, indexed URLs, old emails). It doesn't stop a motivated adversary who already downloaded the file.

Free services with built-in expiry

| Service | Default expiry | Shortest setting | Manual delete? | |---|---|---|---| | HexaTransfer | 14 days | Delete anytime | Yes | | WeTransfer | 3 days (free) | 3 days | Paid only | | SwissTransfer | 30 days | 1 day | Yes | | Tresorit Send | 7 days | 1 day | Yes | | Dropbox Transfer | 7 days (free) | 1 day (paid) | Yes | | Proton Drive share | Configurable | Single download | Yes | | Send Anywhere | 48 hours | 10-minute quick share | Yes |

If 14 days is too long for your situation, most services let you shorten or delete manually. Do both when the material is sensitive.

Link construction: what's in the URL

A typical temporary-file URL looks like:

https://hexatransfer.com/d/abc123def456#key=XyZ987...

The part after /d/ is the blob identifier. The part after # is the URL fragment, which stays in the browser and isn't sent to the server. With end-to-end encrypted services, the fragment carries the decryption key. The server can hand out the encrypted blob; only someone who has the full URL (including the fragment) can decrypt it.

This is why accidentally logging the URL in server logs, chat history, or analytics is bad. The fragment is the secret.

Password protection vs expiry

These solve different problems. Password adds a second factor — even if the link leaks, it's useless without the password. Expiry reduces the time window during which a leak matters. Use both for high-stakes material:

• Expiry: 7 days, max 3 downloads
• Password: 16-character random, sent via SMS separately

Without the password, a leaked link is a 404 to any guesser. Without expiry, a forgotten link sits in an email archive forever.

Self-destruction for messages vs files

Signal's disappearing messages, Telegram secret chats, and Snap's view-once photos handle the same problem in a different context. They rely on clients cooperatively deleting after display, which works against casual oversight but not against a recipient who screenshots or records. Self-destructing file links have the same limitation — the goal is reducing surface area, not preventing determined copying.

Designing your own retention policy

For a small team handling sensitive transfers, pick a default and stick to it:

• Default expiry: 7 days.
• Download cap: match the number of expected recipients (usually 1-5).
• Password: required for anything regulated (PHI, PII, financial records).
• Sharing channel: never the same channel as the password.
• Post-send habit: delete manually once you confirm receipt.

Make this a checklist. Muscle memory is the difference between a policy that's followed and one that only exists in a wiki page.

Try it at hexatransfer.com — 14-day expiry by default, manual delete any time, end-to-end encrypted.