If a file-transfer link has expired, the most reliable recovery path is to ask the sender to check the transfer and re-upload the retained delivery if necessary. Refreshing the page cannot recreate a file that the service has already deleted.
First establish whether the link is actually expired. An incomplete URL, access restriction, missing password, removed file, or temporary service error can produce a similar “unavailable” experience.
What a recipient should check
- Open the complete link from the original delivery message rather than a copied fragment.
- Read the error text and note whether it mentions expiry, permissions, or a missing file.
- Check the stated deadline and time zone in the sender's message.
- If a password is required, confirm it with the sender through the agreed channel.
- Send the exact error wording and delivery version back to the sender.
Do not post a private transfer link in a public forum while troubleshooting. A screenshot can accidentally reveal the link or the names of confidential files; share only what the sender needs.
What the sender should check
Use the transfer's management page, if available, to confirm its status. Determine whether it is still active, whether access settings changed, and whether extension or restoration is actually supported. Do not assume that extending an active transfer can recover a deleted one.
If recovery is unavailable, locate the original delivery package, verify its version, and create a new transfer. Check the recipient link before sending it. Clearly state that the new link replaces the expired one.
Resend the correct files
A working link to the wrong revision creates a new problem. Compare the retained package with the original delivery note. If the content has changed, use a new version name and explain the differences instead of presenting it as an identical resend.
Include the package size and a fresh download deadline. Ask the recipient to download to their own storage and confirm that the required files open. If only one file was missing, you can provide a clearly labeled partial resend.
Understand what expiry can and cannot do
Expiry typically stops future access through that transfer. It does not recall copies that someone already downloaded. Conversely, an expired link is not a backup you can count on restoring later. Keep your own retained copy according to the project's needs.
Separate an expired sharing link from lost source data. If neither the sender nor recipient has a copy and the provider no longer retains the files, there may be no recoverable delivery. Contact the provider for its actual retention behavior rather than assuming hidden storage exists.
Prevent missed downloads
Agree on a realistic access window, especially around weekends, travel, and large downloads. Put the deadline in the delivery message. For ongoing access, consider a shared workspace and an appropriate backup plan instead of relying on a temporary link.
Common questions
Can the sender keep the same URL?
That depends on the service and the transfer's state. A replacement upload may produce a different link. Always test and communicate the link that actually works.
Will changing my computer's date reopen the link?
No. Services normally enforce access on their own systems. Changing the local clock does not restore a server-side expired or deleted transfer.
For future deliveries, compare the retention options discussed in our guide to TransferNow alternatives. Changing services cannot recover an already deleted file.
← All articles