File Link Expiry: How Long Should a Download Link Live?

Two emails, same week, same underlying mistake.

The first: "Sorry, the link's expired, could you send it again?" Your client opened your Friday delivery on Tuesday. WeTransfer's free links now die after three days. You re-upload 4 GB.

The second, eighteen months later: a contractor you worked with once forwards a Google Drive link from an old project to someone you've never met, and it still works. Nobody revoked it, because nobody thought to.

Neither of those is really about the tool. Both are about a decision nobody made: how long should this specific file be reachable?

Expiry is a security control, not housekeeping

Most people treat link expiry as a storage detail. It isn't. It's the cheapest access control you have.

Think about what a share link actually is. It's a credential. Anyone holding it can retrieve the file. It doesn't expire when the project ends, it doesn't care who's holding it, and it works identically whether it came from you or from a forwarded email six people down the chain.

Every other credential in your life expires. Passwords rotate, sessions time out, keycards get deactivated when someone leaves. Share links are the one credential most people issue permanently and then forget about.

An expiry date fixes that automatically. The file becomes unreachable whether or not anyone remembers to clean up, and the window during which a leaked link is useful shrinks from years to days.

The two failure modes

Too short. You re-upload the file, the client feels chased, and you spend an hour on something that was already done. Three days sounds reasonable until it collides with a weekend, a holiday, a timezone difference, or anyone who processes email in batches.

Too long, or never. The file outlives the relationship. A link in an email thread from 2024 still resolves. This is how confidential material ends up somewhere unexpected, and it rarely involves anyone acting maliciously. It's just entropy.

The two look like opposite problems, but they have the same cause: the duration was chosen by the vendor's default rather than by you thinking about the file.

How long each kind of file should live

Here's a starting framework. Adjust for your own risk tolerance.

Content	Suggested expiry	Downloads	Password
Signed contracts, ID documents	24 hours	1 to 2	Yes
Client deliverables, final files	7 to 14 days	3	Optional
Work in progress for review	Length of review cycle	5 to 10	Optional
Internal team files	7 days	Unlimited within team	No
Marketing assets for a partner	30 days	Unlimited	No
Anything under NDA	48 hours	1	Yes
Photos to family	Whatever's convenient	Unlimited	No

Two patterns fall out of that table. The more sensitive the file, the shorter the window and the tighter the download cap. And the more people legitimately need it, the longer it lives but the less each individual access matters.

The rule of thumb: set the expiry to the time the recipient realistically needs, plus one buffer period, and no more. If they'll download it today, two days is generous. If it's going into a review cycle, match the review cycle.

Download limits do work expiry can't

Expiry is a time boundary. A download cap is a usage boundary, and they catch different problems.

Set a limit of 2 on a client deliverable and you've covered the honest case, where they download it and then download it again because they saved it somewhere odd. What you've also done is make redistribution visible. If the link is forwarded to a group of eight people, it stops working after the second one, and you find out.

That's the real value. Not prevention exactly, since anyone who has already downloaded a file can do what they like with it, but a signal. A share that burned through its download limit in an hour tells you something about where the link went.

A caution worth knowing: browsers occasionally issue a partial or repeated request, so setting a limit of exactly 1 on a large file can burn the allowance before your recipient has the file. Two is the safer floor for anything sizeable.

Password protection, and the mistake everyone makes

A password turns a link from "anyone who sees this URL" into "anyone who sees this URL and has the password". That's a genuine improvement.

It becomes worthless the moment you put the password in the same email as the link. If the email is forwarded, both travel together. If the mailbox is compromised, both are exposed. You've added a step, not a control.

Send the password another way. A text message, a phone call, a different messaging app. It takes ten seconds and it's the difference between real protection and a gesture at it. We wrote about why a password alone often isn't enough and what to layer alongside it.

Say the expiry date out loud

The most effective thing you can do costs you one sentence.

Files are ready here: [link]. The link works until Thursday 14 August, and you can download it up to three times. Give me a shout if you need it reopened.

That sentence prevents nearly every expired-link email. It sets the expectation, it makes the constraint feel like deliberate professionalism rather than a limitation, and it gives them a clear action if they need more time.

Compare it to sending a bare link and letting the recipient discover the deadline by hitting it. Same file, same settings, completely different experience. There's more on this presentation layer in how to share large files with clients professionally.

When you shouldn't use expiry at all

Expiring links are the wrong tool for some jobs, and pretending otherwise leads people to build fragile workflows.

Living documents. If the file changes and people need the current version, you want shared storage with permissions, not a series of dated links.

Long-term reference material. Brand guidelines a partner consults for a year should not be on a 14-day timer.

Your own archive. A transfer link is not a backup. When it expires, the file needs to still exist somewhere you control. This distinction is worth understanding properly, and we covered it in temporary sharing versus permanent storage.

The right mental model: transfer links are for handing something over. Storage is for keeping it. Using one for the other job is where most file sharing frustration comes from.

The practical takeaway

Stop accepting whatever expiry your tool defaults to. Whether that default is three days or infinity, it was chosen for the vendor's convenience, not your file's risk profile.

Before you hit send, answer three questions. When does the recipient realistically need this by? How many times should it legitimately be downloaded? Does this file being seen by the wrong person cost me anything?

Thirty seconds of thought, and the expired-link email and the zombie-link leak both stop happening.

How Comfyfile Can Help

Comfyfile puts expiry and download limits in the upload form rather than a settings page, so the decision happens while you're still thinking about the file. Pick an expiry from a few hours up to 7 days on a free account or six months on Pro, cap downloads at whatever number fits, and add a password if the contents warrant it. Per-share download counts show you whether the file was collected and how often, and when the timer runs out the file is removed from EU-based storage rather than sitting there indefinitely.