Private Share or Public Link? How to Share Notes Safely

Sooner or later, a note stops being only yours. A client needs the project handoff. A teammate needs to edit the onboarding guide. Someone on the internet needs to read your setup instructions. All three are "sharing," but they are not the same job, and treating them as one is how notes end up in the wrong place.

This guide compares the two main options: inviting specific people and publishing through a public link. It also gives you a short checklist to run before any branch becomes visible outside your circle.

Two ways to share, two different jobs

Private sharing means you choose who gets access. Each person is a known recipient, and they usually need an account. In an end-to-end encrypted app, this typically involves an encrypted key handoff: the key that unlocks the shared content is passed to the invited person in a way the server cannot read. If you want the background, see end-to-end encryption explained.

A public link means anyone who has the URL can read the content. You are not choosing individual readers anymore. You are choosing to make a piece of content available to whoever the link reaches.

That difference sounds small. It is not. Private sharing is about collaboration with named people. A public link is about publication.

The trust trade-offs, side by side

Question	Invite specific people	Public link
Who can access it?	Only the people you invited	Anyone who has the link
Can they edit?	Yes, if you grant it	Usually read-only, since the point is distribution
Is the audience known?	Yes	No
Can the link be forwarded?	Access is tied to the person	Yes, trivially
Is it still confined to your circle?	Yes	No, by design
Best for	Ongoing work, sensitive material	Documentation, references, announcements

The key point about public links: once content is readable by anyone with a URL, it can no longer be limited to your circle. That is not a flaw. It is what publishing means. But it does mean the strong privacy properties of a private, encrypted workspace do not apply to that specific content in the same way. Treat a public link as a deliberate decision to publish, not as a convenience feature.

Private sharing has its own limits, and they are honest ones. An invited person can copy what they see. Encryption protects content from the server and from outsiders. It does not stop a trusted recipient from taking a screenshot. For a deeper look at where the boundaries sit, read server-side encryption vs. true zero-knowledge.

Scenario 1: the client handoff

You finish a project and need to hand over credentials context, decisions, deliverables and open questions.

Use private sharing. A handoff is almost always specific to one client or team, and it often includes things you would never want indexed or forwarded. Invite the people who need it, give them the access level they need (view or edit), and remove access when the engagement ends.

A tree structure helps here. Put the handoff in its own branch, with sub-notes for decisions, timelines and attachments, so you share exactly that branch and nothing else in your workspace.

Scenario 2: published documentation

You maintain a setup guide, a public FAQ or product documentation that should be readable by anyone, including people who have no account.

Use a public link. The audience is unknown and large, and requiring sign-ups would only add friction. The trade-off is that you must write this branch as if it were a public web page, because that is what it is.

Two habits keep this safe:

• Keep public content in a dedicated branch, separate from working notes, so drafts and internal context never sit under the published node.
• Re-read the whole branch, including sub-notes and attachments, before publishing.

Scenario 3: the one-off reference page

You want to send a recipe, a meeting summary, a config snippet or a reading list to a few people, once.

This is the gray area. A public link is fast, and the stakes may be low, but "a few people" is not "anyone." Ask yourself:

• Would it matter if this link ended up somewhere unexpected?
• Do the recipients need to edit, or only read?
• Will this still be relevant in six months, when you have forgotten the link exists?

If the content is harmless and short-lived, a public link is reasonable. If there is any doubt, invite the specific people. It takes a few more seconds and removes the "who has this link?" question entirely.

A simple rule of thumb

• Do you know exactly who should see it? Invite them.
• Should anyone be able to read it? Publish a link, from a branch built for that purpose.
• Does someone need to edit? Invite them. Public links are for reading.
• Is it sensitive, or will it become sensitive later? Invite them, and keep it private.

A short checklist before anything leaves your circle

Run through this before you make any branch visible outside the people you trust:

1. Open the whole branch. Check every child note, not only the top one.
2. Check attachments. Files and images can contain more than you remember.
3. Look for secrets. Passwords, API keys, personal addresses, internal names, client details.
4. Read it as a stranger. Does it make sense, and is anything in it embarrassing or confidential?
5. Confirm the audience. Is a public link really needed, or would named invitations do?
6. Decide on an end date. Know when you will remove the link or the access.
7. Remember that copies exist. Anything a reader has already saved stays saved after you revoke access.

A more detailed pre-publish review can be built from these points, but even this short version catches most mistakes.

Keep the structure doing the work

The easiest way to share safely is to organize notes so that sharing boundaries match the tree. When a client branch, a public docs branch and your private thinking each live in their own subtree, you decide what to expose by choosing a branch, not by editing individual notes under pressure.

That is the idea behind a private workspace for structured thinking. If you want to try it, you can download TreeNotes or look at the pricing page.