Choose Immich Sharing by Audience, Not Convenience

Use a shared album for selected pictures and known Immich users, partner sharing for an intentionally broad library relationship, and a public link for guests without accounts. These are different permission boundaries, not three interchangeable ways to send the same invitation.

A self-hosted photo library keeps storage under the operator's control, but that does not automatically limit what recipients can see. The useful question is not which sharing button is fastest. It is how much access should continue after the first photo has been opened.

Start with the recipient, then the collection

This comparison assumes a working Immich instance, an account that owns the intended photos or album, and permission to share those pictures. Local album sharing and partner access need other users on the same instance. A public-link recipient does not need an Immich account. Server administration and remote network configuration are separate responsibilities.

Use this short decision list before choosing a method:

• A household member needs one holiday album: prefer an album shared with their account.
• A trusted partner should browse the broader library over time: consider partner sharing after reviewing its scope.
• A guest needs selected event pictures without another account: consider a public link with deliberate access limits.

These choices follow the current Immich sharing documentation. Check the controls available in the installed release before relying on an option; this is a comparison of documented capabilities, not a promise that every older client exposes identical controls.

An album keeps the invitation attached to a selection

Shared albums suit an explicit collection rather than an entire personal archive. Immich allows the owner to choose users on the same instance and assign viewer or editor permissions. A viewer gets read-only access; an editor can contribute their own photos and videos to the album.

For a family trip, viewer access makes sense when one person curates the finished selection. Editor access makes sense when several people are collecting their pictures together. The important distinction is contribution, not whether the recipient is a close friend. A trusted person may still need only viewing access.

The expected result is that the invited account can open the shared collection with its assigned role. Do not assume an album invitation is permission to browse every unrelated picture belonging to the owner. That narrower collection boundary is precisely why albums are preferable to partner access for occasional projects.

Partner access is a continuing library relationship

Partner sharing is substantially broader. The partner-sharing reference documents access to library assets, downloading, metadata including GPS information, and the ability to share assets onward through albums or links. Choose it only when that breadth matches the relationship.

It is also directional. Giving another account access does not automatically provide access to that account's library in return. Each side makes its own sharing decision. Existing partner albums, favorite status, and people or facial-recognition data are not included in the documented scope.

Timeline integration can make partner pictures appear alongside personal pictures. That display choice should not be confused with deduplication across accounts: Immich documents duplicate detection as per-user, so the combined timeline can show duplicates. Partner sharing therefore solves browsing and access, not merging two archives into a single clean ownership model.

A guest link trades account setup for a shareable secret

A public link can expose selected assets or an album to someone without an account. Immich generates a random URL that acts as a secret and supports options including a password, expiry, and permitted actions. Guest uploads are also a documented use case.

This makes a link convenient for an event, but the URL can travel beyond the original message. Treat possession of the link as meaningful access rather than proof of a particular person's identity. A password and expiry can narrow access; neither prevents a recipient from keeping pictures already obtained.

For a viewing-only audience, do not enable contributions merely because an upload option is available. If guests are meant to contribute, make that a separate decision and consider where their submissions will land. The owner remains responsible for the self-hosted storage receiving those files.

A sharing permission does not create a network route

A valid link still needs a reachable server. A home server available only on the LAN will not become internet-accessible when an album is shared. A VPN-only deployment can suit known household devices while remaining inconvenient for one-time guests.

The remote-access guide distinguishes VPN access, Tailscale, and reverse-proxy approaches. It warns against directly forwarding port 2283 to the internet without additional configuration. Do not weaken that boundary simply to make a guest link load. Choose an appropriate remote-access design separately, with HTTPS and the maintenance responsibilities it brings.

Validate the audience boundary before sharing real pictures

Use harmless sample photos for a small acceptance check. The intended recipient should see the intended collection; an uninvited account should not receive private album or partner access. For a protected guest link, a fresh browser session without the required password should not reveal the pictures. Use the actual recipient path, not an owner session that already has broader permissions.

If results are broader than intended, stop distributing the invitation and withdraw the share rather than deleting original photos. The partner documentation identifies User > Account Settings > Sharing as the place to remove a partner. For albums and public links, review the existing share controls in the installed version and verify access again after changing them. Revocation cannot retrieve copies already downloaded.

If the content is correctly restricted but unreachable, troubleshoot the network route independently of the photo permissions. The best choice is the smallest sharing scope that serves the audience, with an access path that those recipients can actually use.