Guide Updated October 29, 2026 # A file or a link? What changes when you share each. Sharing a copy and sharing a pointer feel the same. They are not. The short answer A file hands over a copy that the recipient then controls. A link hands over a way to reach a document that stays under the rules of the system holding it. Links can be ended; files can only be asked to end, and any download turns a link back into a file. A file and a link, side by side Send a file You Their copy - **What you hand over:** A copy - **Who controls it after:** The recipient and their systems - **Can it be ended?:** Only by asking Share a link You A pointer - **What you hand over:** A way to reach it - **Who controls it after:** The system holding the document - **Can it be ended?:** Yes, if that system allows it, but not a download You attach a document to an email, or you paste a link to the same document. On your screen the two actions take the same few seconds, and the person at the other end can open the document either way. What happens next is very different, and most of it is decided at the moment you choose. This guide explains the difference in plain terms, and ends with a short checklist for choosing between them. ## What you actually hand over When you send a **file**, you hand over a copy. The recipient now has their own instance of the document. It sits in their inbox, then often in their downloads folder, their device backup, perhaps a shared drive at their firm. Each of those is a separate copy, governed by whoever runs that place. When you send a **link**, you hand over a pointer. The document stays where it was. The recipient gets a way to reach it, under whatever rules the system holding it applies: who may open it, whether it can be downloaded, and for how long the link works. A useful test is to ask: if I changed my mind tomorrow, what would still be in their hands? With a file, the answer is the file. With a link, the answer depends on the link, the system behind it, and what the recipient did while they had access. ## Who controls access afterwards A sent file is controlled by its recipient. Your firm's rules stop at the edge of your own systems. The recipient's firm decides how long its mailboxes keep attachments, who can search them, and how they are backed up. You can ask them to delete a copy, but you are asking, not deciding. A link keeps control with the system that holds the document. That can be a real advantage: access can be limited to named people, given an end date, or withdrawn. It also means the link is only as good as that system's settings. A link that anyone with the address can open behaves, in practice, much like a file that can be passed on. There is one more thing a link quietly carries: responsibility. When you link to material held somewhere else, that other system's rules, security and retention apply to it. Choosing a link is also choosing whose rules govern the document. ## What happens when access ends With a link, ending access is a real action. If the system holding the document supports it, you can withdraw the link or let it expire, and the pointer stops working. The next person who clicks it sees nothing. With a file, there is no equivalent action. The copy you sent does not have an off switch. Some tools offer to retract a message shortly after sending, but whether that works depends on systems you do not control, and it cannot reach a copy that has already been opened and saved. So the honest summary is this: links can end; files can only be asked to end. ## What happens to downloaded copies Links are not a complete answer either. If a link allows downloading, a recipient who downloads the document now holds a file, with everything that implies. Ending the link afterwards stops further access through the link. It does not reach the download. The same is true of anything a recipient copies by hand: a printed page, a screenshot, a paragraph pasted into another document, a photo of a screen. No sharing method can reach those. What a good system can do is make the boundary clear, limit downloading where the work allows, and keep a record of what was shared, with whom and until when. This is why the moment of sharing matters so much. Most of the control you will ever have is the control you choose to keep when you decide how to share. ## Links can travel too A link is a short piece of text, and short pieces of text are easy to pass on. A recipient can forward it to a colleague, paste it into a chat, or save it in a note. Whether the next person can open it depends entirely on how the link was set up: limited to named people, or open to anyone who has the address. Links are also opened by software, not only by people. Email security tools often open links automatically to check them for threats, and messaging apps may fetch a link to build a preview. A record that a link was "opened" can therefore reflect a machine, not a reader. That matters later, when someone asks who saw the document and when. ## When each one makes sense Neither choice is wrong in itself. A file can be the right answer when the recipient genuinely needs their own copy: a signed agreement they must keep, a document they are obliged to retain under their own rules. In that case the honest step is to accept that the copy is theirs, and to record that you sent it. A link usually fits better when the work is temporary: a review that runs for a few weeks, a set of documents for a meeting, material a colleague at another firm needs to see but not to keep. There, the ability to end access is the point. ## A short checklist before you share - **Does the recipient need to keep a copy?** If not, prefer a link that you can end. - **Who exactly should be able to open it?** Prefer access limited to named people over a link anyone can forward. - **For how long?** Decide an end date now, while you still remember why you shared it. - **Should downloading be allowed?** Every download turns a link back into a file. - **Where will the record live?** Know where you can later see what you shared, with whom, and until when. None of these questions needs special software to answer. They do need to be asked before the document leaves, because afterwards most of the answers are no longer yours to give. How this applies ## In DocuPrivé - A file held in DocuPrivé and a link to material held elsewhere are different things, with different controls. A link does not make DocuPrivé responsible for the other system. Designed, not yet built - Recall is designed to end access that DocuPrivé controls. It cannot reach copies already downloaded, or change permissions in someone else's system. Designed, not yet built - Request details already stay with one verified recipient for a defined period, and access to a Request can be revoked. In our development build, for Request details [Development status](https://docuprive.com/platform/status/) ## Keep reading - [What recall can and cannot do Ending access is real. Un-sending is not.](https://docuprive.com/resources/what-recall-can-and-cannot-do/) - [Share & Recall How access is designed to work in DocuPrivé.](https://docuprive.com/platform/share-recall/) - [Legal & advisory An example matter workflow.](https://docuprive.com/solutions/legal-advisory/) ## Follow what comes next. [Get product updates](https://docuprive.com/updates/) [All resources](https://docuprive.com/resources/)