Sometimes a URL should not be enough to open a file. A team draft, internal PDF or client project can belong to a group of people who already work inside the same Media2URL workspace.
Private access is built for that situation. The recipient opens the link while signed in, and Media2URL checks whether that account has access to the workspace that owns the file.
Someone outside the workspace does not gain the same access simply because the URL reaches them.
Private sharing starts with the workspace that owns the asset. This is the part that makes it different from an Unlisted link, where knowing the working URL is normally enough to reach the file.
With Private access, the link and the signed in account are checked together.
A client file should sit inside the client workspace if that is where access needs to be managed. The same idea applies to an internal team project or a personal workspace. This choice is important because Private access follows the workspace that owns the asset. Putting the file in the wrong workspace also puts its access under the wrong group of members.
Open the file settings and choose Private when that control is available. After that, possession of the URL is no longer enough on its own. The person opening it also needs a signed in Media2URL account with access to the workspace behind the file.
You can send the available link to the person who needs the file. When they open it, Media2URL checks their account access rather than assuming that receiving the URL automatically gives permission. For somebody who is already part of the project workspace, this keeps file access connected to the same membership the team is already using.
Projects do not stay the same forever. A contractor can leave, a reviewer can finish their work, or somebody's workspace role can change. A permitted workspace administrator can update or remove that member when needed. The file link can also be disabled separately, and neither action automatically deletes the stored asset.
A Private link still has a normal URL, but that URL is not the complete key to the file.
The recipient also needs to be signed in to an account that is allowed into the owning workspace. If an authorised member forwards the same URL to somebody outside that workspace, the forwarded link alone does not transfer their membership.
This makes Private access useful when permission should follow an existing team or project relationship. Access stays connected to the workspace rather than spreading to anybody who happens to receive the link.
| Link mode | What gives someone access |
|---|---|
| Public | A working URL |
| Unlisted | Possession of the working URL |
| Protected by a password | The URL and the required password |
| Private | The URL and authorised signed in workspace access |
An Unlisted link is useful when you want to keep a file away from normal public discovery but still allow anyone with the URL to open it. Private access goes further because the workspace account is checked as part of the request.
Password protection takes another route. The recipient proves access by entering the shared password instead of relying on membership in your Media2URL workspace.
Imagine five people are working inside the same workspace. Sending another shared password every time they need an internal file adds a second access system on top of the membership you already manage.
Private access keeps that relationship simpler. The team member signs in with their own account, and access follows the workspace they already belong to.
It also becomes easier when somebody leaves the project. Removing their membership changes their future workspace access without requiring you to remember every password that person received earlier.
Not every recipient should become a workspace member. A client who only needs to inspect one draft, for example, might not need access to the rest of the project area.
In that situation, password protection or an expiry setting can be a better fit where those controls are available. The person gets access to the file without being added to the workspace simply for one short review.
A public website image is another clear example. If anonymous visitors need to load the asset, setting it to Private would block the very audience the page is meant to serve.
Private works best when workspace membership itself is part of the permission you want to enforce.
People inside Team Workspaces can have roles such as Owner, Admin, Editor or Viewer. Those roles decide what somebody is allowed to manage inside the workspace. Private file access checks whether the signed in person belongs to the workspace that owns the asset. So two members can both be allowed to open a Private file while still having different abilities to organise, edit or manage workspace content.
An authorised member can copy a Private link and send it somewhere else. That does not mean the next person automatically receives the same permission. If the forwarded recipient does not have access to the owning workspace, possession of that URL alone does not give them authorised Private access. There is still an important practical limit here. A person who is legitimately allowed to open content can copy or save what they are allowed to receive, so Private access should not be treated as a way to make authorised viewers physically unable to copy information.
Workspace membership answers who should be able to open the file. Expiring Links answer how long the link should keep working. Those controls can be combined where the current file and account support them. A project member can receive access during a review period, then the sharing link can stop after the deadline without turning the file into a public asset. That combination is useful when the people are trusted workspace members but the particular review should not stay open indefinitely.
Suppose a designer uploads product images into a shared client workspace. A month later, the designer leaves the project.
Removing that person's membership changes their future access. It does not automatically delete the images that belong to the team's shared library.
The stored asset has its own lifecycle inside the Media Library. Workspace membership and file deletion are separate decisions.
Sometimes the workspace is still active and everybody should remain a member, but one old draft should no longer open through its previous link.
Disabling that file link handles the individual asset. There is no need to remove members from the project simply because one file should stop being delivered.
The underlying asset can also remain in the library if the team still needs it internally.
| Situation | Useful starting point |
|---|---|
| An image needs to load on a public website | Public |
| Only people who receive the URL should know about the file | Unlisted |
| An outside recipient should enter a shared password | Protected by a password |
| Existing workspace members need the file | Private |
| Workspace members only need access for a limited period | Private + Expiry |
These examples are useful starting points rather than fixed rules. The available combinations still depend on the account, workspace and file being shared.
You can check the broader set of controls under Security & Access.
A designer uploads a banner draft to the client workspace, where the reviewer already has access.
There is little reason to create a broadly accessible link just for that review. Keeping the file Private lets the existing workspace membership handle the permission.
If the reviewer later leaves the project, their access can change with the workspace instead of requiring somebody to track down a separate shared password.
A project PDF can stay useful for months. Sending a fresh attachment every time somebody needs it creates several copies and makes it harder to know which one the team is actually using.
Keeping the document in the workspace gives authorised members one place to return to. Private access keeps the link tied to those members instead of opening it to anybody who receives the URL.
A contractor joins the workspace and needs several project files while the assignment is active. Their membership gives them access to the Private assets required for that work.
When the assignment ends, removing the contractor changes their future workspace access. The shared files stay available to the remaining team because the contractor and the assets are managed separately.
A team can still need an old draft for reference even though nobody should keep opening it through the previous sharing URL.
Disabling that link stops delivery for the file without removing every member from the workspace. The project continues normally, and the asset can remain inside the library if the team still needs it.
Turning an image, PDF, video or another supported asset Private does not create a new file type. The original asset still belongs to the Media2URL library. What changes is the rule Media2URL applies when somebody tries to open it through the Private link. The recipient now needs the required signed in workspace access before that supported file is delivered.
Yes. The recipient needs to be signed in to a Media2URL account that has access to the workspace owning the file. Receiving the URL by itself is not enough to open the Private asset.
No. An Unlisted link keeps the file away from normal public discovery, but somebody with the working URL can still use it. A Private link also checks the recipient's signed in workspace access, so possession of the URL alone does not provide the same permission.
Yes, where that combination is available for the current file and account. Private access decides who can open the file through the workspace. Expiry sets the period for which that sharing route stays active.
That person's future workspace access changes according to the membership action you take. The files already stored in the shared workspace are not automatically deleted simply because one member has been removed.
No. Password protection gives access after the recipient passes the configured password check. Private access is tied to a signed in Media2URL account with permission to use the workspace behind the file. A password can therefore fit an external recipient who should not join the workspace, while Private access fits people whose permission should follow workspace membership.
The forwarded URL does not transfer the sender's workspace membership. A person outside the owning workspace still needs the required account access before the Private file can open. An authorised viewer can still copy content they are legitimately allowed to receive.
No. Private changes the access rule around the file rather than turning the asset into a different file or automatically deleting it. The link, file settings and stored asset continue to have their own management controls.
Not when anonymous website visitors need to load the image. A Private asset requires the appropriate signed in workspace access, so a normal public website cannot depend on it in the same way it would depend on a publicly accessible hosted file.
Next steps
For member roles and workspace permissions.
For Public, Unlisted, Password, and signed delivery controls.
When Private access should stop after a set time.
For managing stored assets separately from link states.
