An expiring download link is a URL that grants access to a file for a limited window, verified by a cryptographic signature instead of a login. It works by encoding a resource path, an expiration timestamp, and a signature into the URL itself, so the file stays private until the link is shared and useless once the clock runs out. You can configure that window by time, by number of clicks, or both.
TL;DR:
- Short-lived signed URLs depend on the resource path, expiration timestamp, and signature, which must be validated on each request to ensure security.
- Cloud providers set maximum durations for signed URLs: AWS CLI/SDK can generate up to 7 days, while console tools and Google Cloud often default to or recommend shorter windows like one hour or ten minutes.
- Generate links at the moment of access for better security, especially when using server-side or application-triggered methods, rather than pre-creating long-term URLs.
- Use short expiration windows of minutes to a few hours for sensitive files, and longer durations of several days only for less confidential, public content.
- When a signed URL expires, it typically returns a 403 or 404 error, and ongoing downloads usually complete but cannot be resumed or restarted afterward.
Table of Contents
- How signed download links work under the hood
- Date-based, click-based, and hybrid expiration policies
- AWS S3 and Google Cloud signed URL limits compared
- Generating expiring links through the console, CLI, or your own server
- Choosing safe expiration windows and hardening your links
- What happens when a link expires
- When individuals and small teams actually need this
- A quicker way to share files that expire on their own
- FAQ
- Sources
How signed download links work under the hood
A signed URL is built from three parts: the path to the file, an expiration value, and a signature generated with a private key or temporary credential. When someone requests the link, the server or storage provider recalculates the signature and checks the timestamp before serving the file. If either check fails, the request is rejected.
The important detail is that the link itself is the credential. Anyone holding the full URL can open it, the same way anyone holding a physical key can open a door, so there is no separate login step checking who is asking.
- The signature ties the link to a specific resource and expiration, so changing any part of the URL invalidates it.
- Validation happens on every request, not just the first one, which is why revoking the signing credential can cut off access early.
- A download that begins before expiration will typically keep running even if the timestamp passes mid-transfer, but a fresh request after that point gets rejected.
Because the URL carries everything needed to access the file, treat it like a password: never post it somewhere public, and avoid pasting it into a chat log or ticketing system that gets archived. For practical advice on secure document sharing, see Secure Document Sharing for Professionals.
Date-based, click-based, and hybrid expiration policies
Most systems that generate temporary links give you one of two core mechanisms, and some combine both.
- Date or time-based expiration sets a fixed window, such as one hour or seven days, and works well for scheduled releases, product downloads, or giving a client a set period to retrieve a file.
- Click or usage-based expiration invalidates the link after a set number of opens, often just one, which suits single-recipient delivery where you want the file gone the moment it's retrieved.
- Hybrid policies apply both limits at once and expire the link whenever the first threshold is hit, so a link set for 24 hours and one click dies after either the clock runs out or someone opens it, whichever comes first.
Pick time-based expiration when the recipient's schedule is uncertain, and click-based when you know exactly who is opening the file and want to close the door immediately after. Hybrids make sense for anything sensitive enough that you want both protections working at once.
AWS S3 and Google Cloud signed URL limits compared
Cloud storage providers set real ceilings on how long a signed link can last, and those ceilings depend on how you generate the link.
With Amazon S3 presigned URLs, console-generated links are capped at roughly 12 hours, and some console download flows produce links valid for as little as 5 minutes according to AWS prescriptive guidance. Generating the link through the CLI or SDK instead raises that ceiling to up to 7 days, giving you far more flexibility for scheduled or delayed access.
Google Cloud works through the gcloud storage sign-url command, which defaults to a 3,600 second (one hour) duration unless you pass a --duration flag, and documentation examples show durations as short as ten minutes for high-security cases.
A common default window across both platforms sits at one hour, per the gcloud sign-url documentation, which is a reasonable starting point before you tune it to your own risk tolerance.
- Console tools favor short, safe defaults because they're built for one-off human use.
- CLI and SDK tools assume a developer who understands the tradeoffs and wants longer or more flexible control.
- In both systems, if the credential used to sign the URL expires or gets revoked, the link stops working even if its own timestamp hasn't passed yet.
Generating expiring links through the console, CLI, or your own server
The right generation method depends on how much control you need and whether you're comfortable with a command line.
The console route works for quick, one-off sharing: upload the file, locate the share or presign option, and set an expiration from the dropdown. It's fast but limited to shorter windows and offers little automation.
The CLI and SDK route gives you precise control. On AWS, aws s3 presign s3://your-bucket/file.zip --expires-in 3600 creates a link valid for one hour, and you can push that up to 7 days. On Google Cloud, gcloud storage sign-url gs://my-bucket/file.txt --duration=10m --impersonate-service-account=sa@my-project.iam.gserviceaccount.com creates a 10-minute link signed under a specific service account.
- Use the console when you need one link, right now, for a single person.
- Use the CLI or SDK when links need to be generated on a schedule or triggered by an application event.
- Use server-side generation when the file is requested by end users through your own product, since it lets you issue a fresh short-lived link per request instead of reusing one long-lived link.
Pro Tip: Generate the link at the moment of request rather than in advance, so the expiration window matches actual need instead of sitting unused in a database or log file.
Non-developers who want expiring links without touching a CLI typically reach for a hosted file-share tool with a built-in expiration setting, which trades fine-grained control for a simpler workflow.
Choosing safe expiration windows and hardening your links
Pick a lifetime based on three factors: how sensitive the file is, how large it is, and how reliable the recipient's timing is. A tax document headed to one known recipient warrants a short, tight window. A public changelog download can safely live for days.
- For automated systems or scripts, issue links lasting 30 to 60 seconds and generate them fresh for every request rather than storing them anywhere.
- For sensitive files going to a specific person, minutes to a few hours is usually enough, especially when paired with a click limit.
- For low-sensitivity downloads like marketing assets or public releases, a window of several days is reasonable.
Combine expiration with other controls where the platform supports them: a one-time-use flag, a referrer or IP check, or restricting the signing credential's own permissions so a leaked link can't do more damage than intended. Practitioner guidance on presigned URLs recommends scoring each use case by sensitivity, file size, and the impact of a replayed link before settling on a duration, rather than defaulting to the same window every time.
Pro Tip: Rotate the signing keys or credentials behind your links on a regular schedule, since a leaked key can outlive any individual link's expiration.
Watch your access logs periodically for unusual download patterns, like the same link being hit from many different locations, which often signals it was shared somewhere it shouldn't have been.
What happens when a link expires
An expired link typically returns a 403 or 404 response, and some CDNs or caching layers may briefly keep serving a cached copy even after the origin would reject a fresh request, which can create confusing edge cases for support teams.
If a download was already in progress when the expiration passed, it generally finishes without interruption, but trying to restart or resume that same download afterward will fail.
- Reissue a new link rather than trying to extend the old one, since most signing schemes don't support editing an expiration after the fact.
- For recurring access needs, consider authenticated access instead of a one-off link, so the recipient doesn't need a new URL every time.
- Log expiration events and build a simple "request a new link" flow so support isn't fielding the same ticket repeatedly.
When individuals and small teams actually need this
The most common mistake I see is picking a lifetime that's convenient rather than correct: a 7-day link because it's easy to remember, or a signed URL pasted into a log file that never gets cleaned up. Both quietly turn a temporary link into a permanent one.
If you're sharing a single file occasionally, a hosted file-share tool with built-in expiration beats writing CLI commands by hand. If you're issuing links programmatically at scale, generate them server-side and keep the window as short as the use case allows.
— Andreas
A quicker way to share files that expire on their own
If writing signing code isn't where you want to spend your afternoon, Pingfloat's File Sharing tool gives you a temporary, secure link from a plain upload screen, no CLI flags or credential setup required.
It's built for the same goal as a hand-rolled signed URL: the file lives at that address only until the link expires, which suits anyone who wants secure, time-limited sharing without touching an SDK. For a one-off transfer or a quick file handoff with a client, it's a faster path to the same result. Try Pingfloat's file-sharing tool the next time you need a link that disappears on its own.
FAQ
What should you do when a download link expires?
Request a new link rather than trying to reuse or extend the old one, since most signed URL systems can't modify an expiration after it's set. If you don't control the link's source, contact whoever shared it and ask them to reissue it.
How do you create a link that expires automatically?
You can generate one through a cloud provider's CLI, such as aws s3 presign with an --expires-in flag or gcloud storage sign-url with a --duration flag, or through a hosted file-sharing tool with a built-in expiration setting. Both methods embed a timestamp and a signature that the server checks before releasing the file.
What happens when you try to download a file from an expired link?
The server typically returns an error such as a 403 or 404 response instead of the file. A download already running before the expiration usually finishes, but a new request made after expiration will be rejected.
What does it mean when a download link has expired?
It means the signature or timestamp embedded in the URL no longer passes the server's validation check, so the link can't be used to retrieve the file anymore. This is the intended behavior of a time-limited link, not an error on your part.
How long should an expiring link stay valid?
It depends on the sensitivity of the file and how it's being delivered: automated systems often use links lasting under a minute, sensitive human-delivered files suit a window of minutes to hours, and low-sensitivity public files can safely use a window of several days, per practitioner guidance on presigned URL tradeoffs.