An expiring download link is a link that stops working on a date you choose, so the files it points to cannot be downloaded after the job is done. Use one whenever a file goes to someone outside your organisation: a short lifetime for one-off hand-overs, a longer one for projects, and no expiry only for material you deliberately want to keep available — in a place built for that, not in a link.
I run Yungle, so I will describe how we do it, but the reasoning applies to any tool that lets you set a date.
Why links should expire
A link is a key, and keys get copied. It is forwarded to a colleague, pasted into a chat, left in an old email that a new person reads years later. Without an expiry, every one of those copies works forever.
An expiry date cleans up after you. The forwarded copies stop working on the same day as the original, whether or not you remember they exist. It is the cheapest security measure there is, because it requires nothing after you set it.
There is a quieter benefit too: storage that nobody needs is still storage, kept on always-on disks. Deleting files is the cheapest carbon saving covers why that adds up.
Choosing a lifetime
Match the date to the job:
| Situation | Sensible lifetime |
|---|---|
| One-off hand-over | About a week |
| Client review round | Until the review deadline, plus a few days |
| Contract documents | Until signed, then remove |
| Project deliverables | Until the project closes |
| Reference material clients return to | No expiry — in a collection, not a link |
The last row is the important one. Material that must stay available is not a link problem; it needs a lasting place with its own address.
Expiry, password, revocation
Three controls, each answering a different question:
- Expiry — until when does it work?
- Password — who can open it?
- Revocation — can I stop it now?
Use all three for anything sensitive. The expiry handles the future you forget about, the password handles the wrong person, and revocation handles the mistake you notice.
On Yungle, free transfers last 7 days by default. With a subscription you set any lifetime up to a year per transfer, or no expiry at all on collections. Passwords are free, you can revoke a link at any time, and a receipt tells you who downloaded before it expired.
The problem with expiry: resending
Expiry has a cost, and it lands on the sender. A client who comes back in three months to a dead link means an email, a search for the right version, and a new upload. For one-off hand-overs that is fine. For work people return to, it is the most annoying part of using transfer links at all — and WeTransfer link expired is one of the most-read pages here for a reason.
The fix is not to stop expiring links. It is to stop using links for things that should last. Deliver the final work into a collection that stays up; use expiring links for everything in between.
What happens when a link expires
Worth knowing so you can tell recipients: on Yungle, an expired free transfer is deleted, not just hidden. The link stops working and the files are removed. That is deliberate — a link that pretends to expire while the files sit on a disk somewhere is not really expiring.
A simple policy
- Every external link gets an expiry.
- The default is short; lengthen it on purpose.
- Anything that must last goes into a collection, not a link.
- Passwords on anything sensitive, sent separately.
- Revoke the moment something looks wrong.
For how long to keep what you do store, see how long to keep client files.