What is a shared file, and why shared means five different things

    Cameron James·
    · 14 min read
    Document sharing

    A shared file is a file more than one person can get to, without you emailing them a copy of it. In plain terms, what is a shared file? It's usually one stored file in one location, with access controlled by permissions so multiple people can open the same item.

    That simple definition hides the part that causes trouble: people use “shared” for several arrangements that behave very differently. The file might still live in one person's account, it might sit in a company-owned space, or it might not be shared at all so much as duplicated. Most of the file chaos I've watched inside small companies comes from two people using the word to mean different things and neither of them noticing.

    How I’m defining shared files in this article

    I’m using “shared file” as a practical umbrella term rather than a product-specific one. To separate the five common meanings, I’m looking at five criteria: where the file is stored, who owns it, who can access it, whether several people are editing the same underlying file, and what happens if the original owner’s account disappears.

    That framework matters because two setups can look identical to the person clicking the link while being wildly different behind the scenes. A PDF sent as an attachment feels shared, but it creates copies. A Google Drive link may keep one live version, but access still depends on the owner's account. A shared drive in Google Workspace or a SharePoint library behaves differently again because the storage belongs to the organisation, not an individual, as documented in Google's Shared Drives overview and Microsoft's SharePoint and OneDrive comparison.

    I use this lens because it's the one that predicts real-world outcomes. From what I've seen, teams rarely get burned by the phrase itself; they get burned when no one asked who owns the file and what survives after someone leaves.

    Sharing a file means five different things

    When people say a file is shared, they often mean “other people can get to it.” That's true, but incomplete. In practice, sharing usually means one stored file plus permission-based access, while emailing an attachment creates a separate copy that immediately starts drifting from the original.

    The useful distinction is not whether the file feels shared, but what happens underneath: does the share create duplicates, who owns the source file, and what breaks if access is revoked? For teams comparing tools, that is also why broader resources like RealEstateCRM's guide tend to discuss collaboration software in terms of access and coordination rather than just sending files around.

    You sent a copy

    The oldest arrangement, and the one people still default to. You attach a file to an email and hit send. There are now two files. Yours changes, theirs doesn't, and within a fortnight nobody knows which is current.

    A familiar example is emailing a contract PDF to a client or a slide deck to a colleague for review. This does create duplicates, the sender keeps ownership of the original copy in their own storage, and revoking access later does nothing because the recipient already has a separate file. Technically this isn't a shared file at all, it's a duplicated file, but that is the image people have in mind when they say they shared something. It's also why version numbers in filenames exist, and why "proposal_final_v3_FINAL.pdf" is a genre.

    You shared a folder

    Same mechanism, wider blast radius. Everything you drop into that folder is automatically shared with the same people, including the thing you dropped in without thinking on a Friday afternoon.

    A typical example is a project folder in Dropbox or Google Drive used for client deliverables. It may contain one source file per item, but the sharing decision applies to the whole container, so new files inherit that access. This doesn't duplicate the files, and the folder owner usually remains the person or team account that created it, but revoking access later can be messy because it affects everything inside. Folder sharing is where accidental disclosure happens in small businesses. Not hacking. Somebody saving a payroll spreadsheet into a folder that six contractors can read.

    The file lives in a shared drive

    A shared drive (Google's Shared Drives, SharePoint document libraries, a Dropbox team space) is owned by the organisation rather than by a person. Files in it belong to the company. When someone leaves and their account is deleted, the files stay.

    Think of a team brief in Google Shared Drives, a policy document in SharePoint, or a sales proposal stored in a Dropbox team space. There is still one live file rather than many duplicates, but the owner is effectively the organisation's workspace, not the employee who happened to upload it. If access is revoked, the file remains in the company-controlled location for everyone else with permission. If you employ anyone, this is the arrangement you want for anything the business depends on.

    The file is a live collaborative document

    A Google Doc, a Notion page, a Figma file. Several people can be inside it at the same time and the file is really a stream of changes rather than a static object. "Shared" here means co-authored, not just readable.

    A recognisable example is a design file in Figma, a draft spec in Notion, or a planning doc in Google Docs with three people editing at once. These usually avoid duplicate versions because everyone works in the same live document, but ownership still depends on where the document lives: a personal workspace behaves differently from an organisation-owned one. If access is revoked, collaborators lose entry immediately, though the underlying work may persist for the team if it sits in a shared workspace. Useful for working things out together. Not what you want when you're sending a finished thing to a client, because it invites editing and it shows them your comment history if you haven't cleaned it up.

    How shared files work in practice

    Most shared-file workflows follow the same pattern, even if the buttons look different across Google Drive, OneDrive, Dropbox, SharePoint, Figma, or Notion.

    1. Store or upload the file in a service that supports sharing.
    2. Choose who should have access: named people, a group, or anyone with the link.
    3. Set their permission level, usually view, comment, or edit.
    4. Send the invitation or copy the link.
    5. The recipient opens the same underlying file from email, chat, or a "Shared with me" view, rather than downloading a separate attachment.

    That last point is the part people miss. A proper shared file is not magic; it is a pointer to one stored item plus a permission rule. In practice, once a team understands that, arguments about “which version is right” drop fast because there is only one version to point at.

    Access also depends on the platform's navigation. In Google Drive, recipients commonly find files in Shared with me. In OneDrive and SharePoint, shared items appear through OneDrive sharing views and links. In Figma, people usually open the file from the direct invite or team project view, and Figma's sharing settings control whether they can view, inspect, comment, or edit.

    One market signal explains why this model now feels normal rather than novel: the enterprise file sync and share market reached USD 13.3 billion in 2025, with cloud deployment taking roughly two-thirds of the market, according to Global Market Insights. Browser-based access and centralised sharing are no longer edge cases. They are the default setup for a lot of teams.

    The difference matters most when someone leaves

    If your business documents are shared links from an individual's personal cloud account, then that person is a single point of failure. They leave, the account gets closed, and every link anyone ever saved breaks at once. Contracts, brand assets, the pricing sheet that three people bookmarked. Nobody has to do anything wrong for this to happen. Somebody just resigns, IT closes the account on schedule, and a year of client work goes with it.

    I've seen the small-company version of this more than once: the "shared drive" turned out to be one operations manager's personal cloud folder with a neat naming system and years of tribal trust built around it. It worked fine until deprovisioning day. Then old links in onboarding docs failed, the latest templates vanished, and nobody could tell whether the surviving attachments in inboxes were current.

    The platform distinction is not theoretical. Google states that files in Shared Drives belong to the team rather than an individual, while Microsoft draws a similar line between personal OneDrive storage and organisation-managed SharePoint libraries in its storage guidance. Mini-scenario: if a salesperson stores pricing sheets in their own OneDrive and shares links externally, those links can fail when the account is removed; if the same files sit in a SharePoint team library, the person can leave and the documents still persist under company ownership.

    The fix costs nothing. Put anything the company relies on in a drive the company owns, not in a folder owned by a person. Ten minutes of moving files now beats a fortnight of archaeology later.

    Permissions are the actual product

    When you share a file, you're really making a permissions decision. The file itself is usually the easy part; the hard part is deciding who can reach it, what they can do, and whether the access should outlive today's task.

    A simple checklist catches most mistakes:

    • Viewer, commenter, or editor: can they only read, can they leave feedback, or can they change the file?
    • Specific people or anyone with the link: is access tied to named identities or to possession of the URL?
    • Expiry date: should this access stop automatically after a client review or vendor handoff?
    • Download or copy restrictions: do you want people to view the file without saving their own copy?
    • Ownership location: is the file stored in a person-owned account or in an organisation-owned workspace?

    This is also where the "shared file" label hides risk. Google documents link-sharing choices and role levels in its Drive sharing controls, and Microsoft explains similar options for OneDrive and SharePoint permissions. The settings sound small, but they determine whether sharing is controlled collaboration or casual leakage.

    A safe internal share looks like this: a finance spreadsheet stored in a SharePoint team library, shared with specific people in finance as viewers or editors depending on role, with no public link and no reason for the file to leave that workspace. A risky overshare looks like this: a folder in someone's personal Google Drive set to anyone with the link, containing a proposal, an old customer export, and a draft pricing sheet someone dropped there for convenience.

    "Anyone with the link" is the setting that causes real problems, because links get forwarded, pasted into Slack channels and saved in browser histories. It is convenient and it's fine for a menu or a public brochure. It is not fine for anything with a price, a name or a number in it.

    "Specific people" costs you one extra step and removes almost all of the risk. If you take one habit from this post, take that one. I've written more on this in the best way to share files with external users, which goes deeper on the client-facing side.

    There is also a behavioural reason to be strict. The numbers are old but telling: a 2022 OpenText report found 56% of U.S. employees use personal file-sharing services for work, and a 2014 Globalscape survey found 63% admitted using personal email for sensitive work documents, both collected in TransferChain's file-transfer statistics roundup. That matches what I've seen in practice: a file often starts in the approved workspace, then detours through someone's personal inbox or chat app because it felt faster in the moment.

    When a shared file isn't the right answer

    Shared files are built for people who already work together. They have accounts, they know what they're looking at, and nobody has to explain the document to them.

    Sending a document to someone outside your company is a different job wearing the same clothes. They don't have an account and shouldn't need one. They'll open the thing once, alone, probably on a phone, with nobody there to tell them which bit matters. And you'll have no idea whether they read past the first page.

    That gap is what we built LiveDocument for. You record a short video walking through the document, it sits next to your PDF or image behind a single link, and you can see which pages they actually spent time on. Clickable highlights jump the video to the section they're reading. It isn't storage and it isn't a shared drive, so it won't replace Google Drive for your internal files. It's for the moment a document leaves the building and you want it to land.

    For everything internal, a shared drive and sensible permissions is the correct answer and always has been. If you want the mechanics of turning a document into a link people can open, file to URL covers it step by step.

    Common questions about shared files

    What is a shared file?

    A shared file is one stored file that more than one person can open because access has been granted to them. The important part is that people are usually opening the same underlying file, not separate emailed copies.

    How do I create a shared file?

    Upload or save the file in a service that supports sharing, such as Google Drive, OneDrive, Dropbox, SharePoint, or a collaborative workspace. Then choose the people or link settings, set their permission level, and send the invitation or share link.

    How do I access a shared file?

    Usually by opening the invite link you were sent, or by finding it in a "Shared with me," shared, recent, or team-space view depending on the platform. If the file was shared with specific people, you may need to sign in with the exact account that was granted access.

    Where is my shared file?

    That depends on the tool. It may live in another person's account, in a shared folder, or in an organisation-owned space such as a Shared Drive or SharePoint library. If you can open it but can't find it later, check your platform's shared-items view before assuming it was deleted.

    How is a shared file different from a shared folder or an attachment?

    A shared file gives access to one item. A shared folder gives access to everything inside it, now and in the future. An attachment is different again because it creates a separate copy in the recipient's inbox or downloads folder instead of keeping everyone on one live file.

    Who owns a shared file?

    Whoever's account or workspace it lives in. That's often a person, which becomes a problem when they leave. Files stored in an organisation-owned shared drive belong to the company instead, and survive individual accounts being closed.

    Can I stop sharing a file after I've shared it?

    Yes, in any cloud storage tool, but you have to close every route in. Remove the person's direct access and disable the link, then check whether they can still reach it another way: shared-drive membership, or organisation, team or folder permissions can each keep access alive on their own. Once every path is closed it stops working immediately, unless they've already downloaded a copy. Doing this occasionally as a tidy-up is a good habit, because people often do not revoke access.

    Is a shared file the same as a shared drive?

    No. A shared file is one item you've granted access to. A shared drive is a storage space owned by an organisation where everything inside it is shared by default. Same word, very different consequences when someone leaves.

    Shared files handle the inside of your business fine. It's the documents you send outside it that go quiet, which is the bit I got tired of guessing about and ended up building livedocument.com to fix.

    About the Author

    Cameron James

    Cameron is the founder of LiveDocument. He writes about sharing documents, PDFs, decks and contracts, and why pairing a video walkthrough with a document beats sending it cold.