How to make a download link that expires automatically: 11 common mistakes (and the fixes)

If you’re searching for how to make a download link that expires automatically, you want one thing: a link you can send today that stops working later without you remembering to revoke it. That’s exactly doable, but it’s also easy to get wrong in ways that leave the file accessible for weeks (or forever), or annoy the client with “access denied” too soon.

Below are the most common mistakes we see when creatives deliver finals, review cuts, galleries, CAD packages, or stems, plus the fix for each. (We build LetsSend, a private large-file transfer service, so we spend a lot of time debugging “why is this link still alive?” and “why can’t my client download?” problems.)

Quick reality check: what “expires automatically” actually means

An expiring link only works if the service hosting the file enforces an expiry date (and ideally deletes the file when it expires). Simply typing “expires in 7 days” in your email, or renaming a folder “DELETE LATER”, does not make a link expire.

In practice you have three common ways to get expiry:

• File-transfer links (WeTransfer-style): designed for expiry by default.
• Cloud storage share links (Drive/Dropbox/OneDrive): can work, but expiry controls vary by plan and organisation settings.
• Self-hosted or developer-generated links (for example time-limited “signed” links): powerful, but usually not what most freelancers want to maintain.

Mistake 1: Using a cloud storage “anyone with the link” share and assuming it expires

This is the classic one. You share a folder from cloud storage, paste the link, and mentally set a reminder that you’ll “turn it off later”. Then you get busy and it stays accessible.

Fix

Use a tool that has expiry as a first-class setting, or confirm your storage tool supports expiry on the specific link type you’re creating. If your client delivery must expire for privacy or contractual reasons, a dedicated transfer link is usually the least surprising workflow.

Mistake 2: Picking the wrong thing to expire (folder link vs file link vs request link)

Many services have multiple link types: a link to a folder, to a single file, to a “file request” page, or to a shared space. You might expire one… while another link to the same content still works.

Fix

• Decide what the client should access: one package (ZIP), one file, or a folder that may change.
• Create one link that matches that intent.
• Before sending, open an incognito/private window and test that only that link provides access.

If you’re sending a project bundle, packaging it as one archive can reduce stray links. (If you need a clean packaging workflow, this pairs well with How to send a whole project folder in one link (without breaking anything).)

Mistake 3: Relying on “remove access” instead of expiry

Manual revocation is not the same as expiry. It depends on you remembering, having permissions, and not being mid-shoot or on a plane when the deadline hits.

Fix

Set an expiry date at link creation time. If you’re using a transfer-link tool, expiry should be automatic. For example, with LetsSend, Free links expire automatically after 7 days and Pro links can be set up to 30 days (as of August 2026). This removes the “oops, I forgot to turn it off” failure mode.

Mistake 4: Setting the expiry too short for real client behaviour

In real life, clients download at the worst time: on a phone, on hotel Wi‑Fi, during a site visit, or after they’ve forwarded your email to someone else internally. If your link expires tonight and they try tomorrow morning, you just created an emergency.

Fix

• For client delivery, a common safe baseline is 7 to 14 days, unless there’s a strict requirement to shorten it.
• If approvals take time, use a longer expiry and add a note like: “Link expires on Friday.”
• If you truly need short access, consider adding a download limit (where available) rather than a very short time window.

Lived detail: we often see downloads fail when someone tries to pull a 6GB export on flaky café Wi‑Fi. If your expiry is tight and they need to restart, they can run out of time even though they “started before expiry”.

Mistake 5: Forgetting that forwarded links are still valid

Expiry does not prevent forwarding. If your client forwards the link to a teammate, that teammate can download until the expiry hits (unless you’ve added additional controls).

Fix

• Use password protection for anything sensitive, and send the password separately.
• Where available, use a download limit (useful for “one-time-ish” delivery), especially for finals.
• Write your email assuming it will be forwarded: include context and the expiry date.

If you want a deeper workflow for passwords, see How to send a password protected file to someone securely (video editor workflow).

Mistake 6: Assuming the file is deleted when the link expires

Some services only disable the link but keep the file stored indefinitely. That can be fine, but it’s not the same as “expired means gone”. If your goal is privacy, retention matters.

Fix

Check the retention behaviour. With LetsSend, expired transfers are deleted rather than quietly archived. If you’re using another platform, look for a clear data retention statement in their help or legal pages.

If you want to see how we handle privacy, retention, and deletion, read how we handle your data, and if you want to know who’s behind the advice, see the team behind LetsSend.

Mistake 7: Adding an expiry date but sharing the wrong version anyway

You upload “Final_v7_REALFINAL_2.mp4”, generate a lovely expiring link, then later realise you exported the wrong audio mix or an earlier grade. Now you either need to send a second link (with a different expiry), or keep both alive longer than you wanted.

Fix

• Do a 10-second preflight: open the file you’re sending (or scrub the video) after export.
• Package deliverables in a clearly named folder/ZIP with a simple manifest (a short text file listing what’s inside).
• If you need to replace content, consider generating a new link and explicitly telling the client to ignore the previous one.

Mistake 8: Using expiry to “secure” a link that is otherwise public

Expiry reduces exposure time, but it does not stop someone from downloading the file while the link is live, saving it, and sharing it later. If you’re sending sensitive material, expiry alone is not a security plan.

Fix

• Combine expiry with password protection.
• Send the password via a different channel than the link (for example, link by email, password by chat).
• For highly sensitive work, consider whether you need client identity controls (which some enterprise tools offer) rather than a simple link.

Mistake 9: Getting tripped up by caching, previews, and “it still works for me” tests

You expire a link, but your own browser still opens a preview (or seems to), so you assume expiry failed. Sometimes you’re seeing a cached preview, or you still have an authenticated session in that service.

Fix

• Test expiry in a private/incognito window where you are not logged in.
• If possible, test from a second device (phone on mobile data is a good reality check).
• Look specifically for download behaviour, not just a thumbnail preview.

Mistake 10: Choosing a method that fights the size of your files

Some workflows technically support expiring links but become painful with large transfers: slow uploads, upload timeouts, or the temptation to recompress a video that is already efficiently compressed (wasting an hour and reducing quality).

Fix

Pick a method designed for large files. Transfer-link services exist for a reason.

One design detail that helps reliability: with LetsSend, files upload straight from your browser to encrypted object storage, rather than being relayed through a middle server. That reduces moving parts. (Uploads can still fail on unstable connections, but fewer hops helps.)

If you’re troubleshooting repeated failures, the Help Center is the fastest place to start.

Mistake 11: Not documenting the expiry expectations for the client

Even if you set expiry correctly, clients get confused when a link disappears. Then you get the “your link is broken” email two weeks later.

Fix

• Put the expiry in the message: “Link expires on DATE.”
• If the work is time-sensitive, add: “Please download and save a local copy.”
• If you will re-send after expiry, say so, and define the process.

Options that support expiring download links (quick comparison)

If you want expiry without babysitting, here’s the practical landscape. Exact limits and features can vary by plan and organisation settings, so treat this as a starting point.

A simple workflow that works (and stays sane)

1. Package the deliverable (single file or ZIP folder) and do a quick preflight check.
2. Upload using a transfer-link tool with automatic expiry.
3. Set expiry first, then add password protection if needed.
4. Test in incognito before you send.
5. Send the link with the expiry date stated clearly, and send the password separately.

If you want the fastest path: create an expiring link in minutes

If you just need to deliver a file and have the link expire automatically, you can send a file free with LetsSend. Free transfers support up to 5GB per transfer (and 5GB/day) with links that expire after 7 days (as of August 2026). If you need bigger deliveries, you can compare Free and Pro (Pro supports up to 200GB per transfer and link expiry up to 30 days, at $12/month).

If you have questions about a specific workflow or a tricky client situation, you can also contact us.