When the question is who should be allowed to open the link.
File access based on time
Expiring links for files that only need to stay available for a while
A file can stay in your account long after the link you sent to somebody has finished its job. A client may only need access during a review, while the original draft still needs to remain available to your team afterwards. Expiring Links is about separating those two things.
The expiry setting puts an end time on access through the shared link. It does not turn the file itself into a temporary upload, and it does not automatically delete the stored asset when that time is reached.
That distinction becomes useful when you want to keep the file but no longer want an old public link to remain usable.
Link lifetime and file lifetime
The link can end while the file stays
Expiry is easier to understand when the shared link and the stored asset are treated as separate things. The file can remain inside Media2URL while access through one link ends at the selected time.
Suppose a design is still useful internally after a client finishes reviewing it. Deleting the asset would remove something the team still needs, while leaving the old review link open serves no useful purpose. An expiry setting lets those two timelines be different.
The same idea applies when a file has several reasons to remain in the library. It might be needed for another project later, kept as part of the file history or shared again through a new link. The old external address does not need to stay active simply because the file itself still has value.
Expiry therefore changes access through the link rather than the nature of the uploaded file. The uploader used to create the asset still decides its accepted format, file limits and other available settings.
Time based access
Expiry does one job
Expiry decides how long a link stays active. It does not decide who is allowed to open it.
That is why a file can still need Private access or a password even when the link expires tomorrow. The timer only controls the length of access, not the identity of the person opening it.
The same separation applies to downloads and view limits. Those controls deal with different parts of the sharing process.
Control comparisons
Similar controls can lead to very different results
| Control | What it changes |
|---|---|
| Expiry | How long the link keeps working |
| Private access | Who can open the file through workspace access |
| Password protection | Whether the recipient has to enter the configured password |
| View or download limits | How many allowed uses can happen before access stops |
| Disable link | Stops access before the selected expiry time |
| Delete asset | Handles the stored file itself |
These controls can sit beside each other where the upload route supports them. They are not replacements for one another.
For example, a confidential document that expires in two days is still available to whoever can reach the link unless another access control restricts it.
When expiry fits
Use it when the shared access has a clear end
Expiry works best when you already know that somebody's access is temporary, even though the file itself may still be useful afterwards. A client review that ends this week is a good example. So is a support file that only needs to remain reachable while the issue is being investigated.
The useful question is not whether the file is temporary. It is whether the shared access has a point where it should naturally stop.
That is why the same feature can make sense for a saved document, an image kept in the library or another supported asset that still needs to remain in the account after the external link has expired.
A website asset is a very different case
An image used on a live website can be requested again every time somebody opens the page. The same is true for files linked from long term documentation or resources that people return to regularly.
If that URL expires while the page still depends on it, the asset can stop loading even though the page itself is still live.
For this kind of use, a normal link is usually a better fit. Expiry is much more useful when the sharing period is known from the beginning.
Temporary Upload starts from a different idea
Temporary Image Upload and Temporary File Upload start with a different intention. You use those tools because the file is being shared for a limited period from the beginning.
Expiring Links is broader. A file can already belong in the normal Media2URL library and still need one shared link that should stop working later. The asset may remain useful long after that particular access window ends.
From the recipient's side, both links can eventually become unavailable. The difference is why the file was uploaded and whether it still needs to remain part of your account afterwards.
Expiry does not pull back files that were already downloaded
Suppose somebody downloads a document while the link is still active. When the timer ends later, Media2URL can stop serving the old link, but it cannot remove the copy already saved on that person's device.
If local downloads are a concern, expiry alone does not solve that problem. Check the controls available under Security & Access because download behaviour is handled separately where supported.
A view limit does not work like a timer
A seven day link is controlled by time. It can remain available during that period unless another setting stops access sooner.
A one view setting is controlled by use instead. If the allowed viewing opportunity has already been used, access can stop even though only a few minutes have passed.
Both can make a link unavailable later, but they reach that point in different ways.
You can stop access before the expiry time
Sometimes a link becomes unnecessary earlier than expected. A client approves the draft on the second day, the support case is resolved quickly, or a contractor no longer needs the file.
Where the dashboard provides the option, the link can be disabled without waiting for the expiry timer to finish. The underlying library file can remain in place if you still need it internally.
Before you use expiry
A few checks are worth making first
- Make sure the file really has a limited sharing period. A permanent website asset can break later if its URL expires while another page still depends on it.
- Remember that expiry stops future access through the link. It does not remove a file that somebody already downloaded earlier.
- Treat privacy separately from time. A link that expires soon is still not private unless an access control also restricts who can open it.
- Check the duration choices shown by the current uploader. The available periods can differ between upload tools and plans.
Questions about expiring links
Frequently asked questions
The uploader can show choices such as 1 Day, 1 Week and 1 Month. Longer periods such as 1 Year or Lifetime can also appear in regular upload flows where the current account supports them. The exact list is shown inside the uploader you are using, which is important because temporary upload pages and regular upload pages do not always offer the same choices.
The link stops providing its normal access after the selected time is reached. Anybody opening the old URL then sees the current expired or unavailable state. The original file can still remain in the Media2URL account unless it is separately removed or managed through the file controls.
Where that combination is supported, yes. Private access controls who can open the file, while expiry controls how long that access route remains active. They solve different parts of the same sharing problem.
Yes, if the normal file controls available for that asset allow it. The expiry timer does not force the file to remain stored until the selected period ends. Deleting the asset and letting the link expire are separate actions, so the right choice depends on whether you only want to stop access or remove the stored file as well.
No. If the file was downloaded while the link was still active, that saved copy stays on the recipient's device. Expiry only stops later access through the Media2URL link.
No. Expiry is based on time, while one view access is based on how many allowed uses have happened. A one view link can stop almost immediately after it is opened. An expiring link continues until the selected time unless another control stops it earlier.
Usually not when the website needs the same image to keep loading. Once the link expires, a page that still points to that URL can lose access to the asset. A stable link is more suitable for files that are expected to remain part of a website or long term document.
Expiring Links refers to a time control used with supported uploads. Temporary File Upload is a separate workflow designed around short term sharing from the beginning. Both can create access that ends later, but the available duration choices and upload flow are not necessarily the same.
Next steps
Explore related access and upload tools
For view limits, downloads, password controls and disabling.
For files created specifically for short term sharing.
For image sharing for a short period.