Sharing Without Losing the Boundary
Immich does not have one generic “share” action. It offers several ways to expose media, and each one changes the audience, the permission scope, the metadata that may travel with the asset, and the way access can end. This chapter compares shared albums, partner sharing, and public links so a reader can choose by trust and scope rather than by convenience alone. It also connects those choices to the infrastructure that must keep the archive private and recoverable.
The question is not simply whether another person can see a photo. It is whether they can see one selection or an entire library, add material, download originals, receive location metadata, access a link without an account, or continue to see the asset after the operator changes their mind.
A shared album is a limited collaboration space
Shared albums are for users on the same Immich instance. The owner chooses the people who can access the album and assigns each a permission level: an editor can read and write within the shared album, while a viewer has read-only access. Shared users can view the album and, where their permission allows, add their own photos and videos.
That scope is narrower than sharing a whole library. It fits a particular event, project, or family selection in which the participants are known accounts on the same server. The owner can keep the rest of the personal timeline outside the collaboration. The access decision is attached to the album rather than automatically attached to every asset the owner has ever stored.
The distinction between editor and viewer is important because “can see” and “can change” are different permissions. A viewer may be appropriate when the purpose is to let someone browse a collection without letting them contribute or alter its organization. An editor is appropriate when the album is a joint collection, but the owner still needs to understand what write access means for the shared space. The documentation describes these roles at the album level; it does not turn a shared album into a general account-sharing arrangement.
Shared albums also preserve the difference between a person’s private library and a collaborative view. A photo can be included in a shared collection without making every other album, archive state, or personal setting visible. That makes shared albums the least expansive of the three sharing patterns discussed here, provided the operator is comfortable creating accounts for the intended participants and keeping the server’s account boundary intact.
The album model is especially useful when the collection itself is the boundary. For example, a group can contribute to one event album while each member keeps unrelated photos private. An editor/viewer distinction then answers two separate questions: who should participate in the collection, and who should be allowed to alter it? The owner does not have to solve a library-wide privacy question to enable a narrowly defined collaboration.
Partner sharing expands the scope to a library
Partner sharing is a different decision. It allows one user to share their entire library with another user of the instance. The partner can view and download assets, and the documented scope includes non-archived and trashed photos and videos along with metadata such as GPS information. This is not just a larger album; it is a relationship between two libraries.
The scope is broad, but it is not identical to copying ownership or merging two accounts. Partner sharing is one-way. To see the other person’s assets, the other person must also share their library.