How to send files that delete themselves.
Most shared files outlive their purpose by years. The tax documents you emailed an accountant in 2021 are still sitting in both mailboxes, and the drive link you made for one contractor still works for anyone who ever had it. An expiring transfer flips the default: the file exists to be delivered, it gets delivered, and then it is gone from the server. Here is how self deleting file links work, how to pick the right lifespan, and what they honestly cannot do.
Why you would want a file to disappear
Three reasons, in rising order of seriousness.
Hygiene. A delivery link is clutter the moment the download finishes. Expiry means no cleanup day, no orphaned files under some cloud account, no quota slowly filling with finished business.
Control. A permanent link forwards forever. The gallery you shared with one client can be pasted into a group chat a year later and it still works. A link that died on Thursday cannot leak on Friday, whatever inbox it ends up in.
Exposure. Contracts, IDs, financial statements, unreleased work: for sensitive material, every server the file rests on is a place it can be breached, subpoenaed or simply forgotten. Shrinking the window from forever to 24 hours shrinks that exposure by the same amount. Security people call this data minimization, and it is the same instinct as shredding paper instead of filing it in a shed.
None of this requires secrecy as a motive. It is simply what delivery looks like when someone designs for the file having a job, doing it, and leaving.
How a self deleting transfer works
With Kepla File Transfer the expiry is a first class choice, not a buried setting:
- Drag files in, up to 10 GB in a transfer. They are zipped while uploading and stored encrypted, exactly as sent.
- Pick the lifespan: 1 hour, 6 hours, 24 hours, or 3 days. This is the moment you decide how long the file exists.
- Send the private link, or address up to 10 recipients so each gets an individual link with a download receipt.
When the clock runs out, the files are deleted from the server and the link stops resolving. There is no account behind it, so there is also no forgotten library of past transfers attached to your identity; each transfer is its own short story with an ending.
The receipts matter more with expiring links than anywhere else. Because the window closes on its own, you want to know the download happened before it does, and per recipient receipts tell you exactly that, in time to resend if someone slept through the window.
Choosing the right lifespan
Pick the shortest window that respects the recipient’s reality.
- 1 hour is for live handoffs: the recipient is waiting, the file moves now, and nothing lingers. Sensitive documents travel well at this setting.
- 6 hours covers same day delivery to someone in meetings, with the link dead by evening.
- 24 hours is the everyday default for clients in your timezone: room to download tonight or tomorrow morning, gone by the weekend.
- 3 days is for other timezones, busy clients and weekend deliveries, and for working handoffs like sending RAW files to an editor who may start Monday.
Whatever you choose, say it in the message: this link expires Thursday at noon, save the files somewhere permanent. Recipients treat expiring links with more urgency than permanent ones, which is a quiet bonus. Deliveries stop pooling in the someday pile because someday has a date on it.
What expiring links do not do
An expiring link controls the server copy, not the world. Be clear eyed about the boundary.
The recipient keeps their download. That is the point of delivery. Expiry is not remote deletion from their laptop, and any service implying otherwise is selling something. If the person cannot be trusted with the file, no transfer feature fixes that.
It is not DRM. Files can be copied, forwarded and screenshotted after download, the same as any file anyone has ever received.
It is not your backup. Once the link expires, the server copy is gone for you too. Deliver from your own organized archive, never treat the transfer as the archive itself.
What it does deliver is exactly what most sends need: the file arrives intact, the exposure window is small and chosen by you, receipts prove the handoff, and nothing about the transaction outlives the transaction. For the rare cases beyond that, end to end encrypted messengers with disappearing messages, or simply handing over a drive, remain the tools of last resort.
FAQ
How do I send a file that deletes itself?
Use a transfer service with expiring links. With Kepla File Transfer you pick a lifespan of 1 hour, 6 hours, 24 hours or 3 days when you send; when it ends, the files are deleted from the server and the link goes dead.
Does the recipient lose the file when the link expires?
No. Anything they downloaded before expiry is theirs, at full quality. Expiry removes the server copy and stops new downloads, it does not reach into the recipient’s computer.
Are expiring file links secure?
They shrink the exposure window, which is a real security gain, and Kepla transfers are encrypted with private links. But expiry is not DRM: after download, the recipient can do anything with their copy.
What happens if the client misses the download window?
You send again, which takes a minute. Download receipts show whether each recipient has pulled the files, so you can nudge or resend before the link dies rather than after.
Why not just use a permanent cloud link?
Permanent links forward forever and accumulate: quota fills, old shares stay live, and cleanup never happens. An expiring link does the delivery and then removes itself from the list of things you have to remember.
Send up to 10 GB without an account.
Drag the files in, pick when the link should expire, and send. Files are zipped while they upload, stored exactly as you sent them, and deleted on schedule. No sign up, nothing recompressed.