share-note: publishing an Obsidian note that looks like your vault

One command, and the point is fidelity

Share Note publishes a note to the web. The description is that you can share or publish a note with your full theme and content exactly as you see it in Reading View, and the goal is that the shared note looks identical to how it looks in your Obsidian vault.

The entry point is the Share Note command, which you can reach from the command palette or from the three-dot menu on any note, where the item is called Share note on the web.

The fidelity claim is the whole proposition, and the feature list is organised by the Obsidian content types it preserves. Images are supported. Dataview queries are supported, with the README showing an inline query and the rendered result on the shared page. Callouts are supported. Code blocks are supported, with a JavaScript example shown rendered. Checkboxes and tags work, with the example showing a task list and inline tags on a heading line.

Links between notes are the interesting one, because it is the hardest. If your shared note links to another note which is also shared, that link also functions on the shared webpage. And a table of contents can be shared so readers can jump around the document, which is what the internal links section describes.

Installation is through Obsidian itself: the plugin is listed in the community plugin directory, and the README points to the documentation site for the setup steps and the public roadmap for planned features.

function doYouEven(haveToAsk) {
  return 'Of course we can do it!'
}

The project is MIT licensed, written in TypeScript, the default branch is main, and the last push was on 2026-10-16 with version 1.6.2 published the same day and 1.6.0 and 1.6.1 on 2026-09-04. There is a system status page, a documentation site at docs.note.sx, and a public roadmap at note.sx/roadmap.

Encryption by default, and the key lives in the fragment

The security model is the most distinctive part of this plugin, and the README is unusually direct about it.

The content of a shared note is encrypted by default. You can read the note, and the person you send it to can read the note, but nobody else can read the content, and the README stresses that this includes the hosting server.

The mechanism is visible in the link format. An encrypted share link looks like this:

https://share.note.sx/4earajc8#PtC3oQDjDQK9VP7fljmQkLBA/rIMb2tbFsGoG44VdFY

The part before the hash is the link to the file. If you open that on its own, you see a message saying it is an encrypted note, because you have not given the decryption key. The key is the second part of the link, after the hash symbol, and combining the two produces a link that decrypts and shows the content.

The key only exists inside your vault and is known only to you and whoever you receive the link from. That is a real property and also a real risk: the key travels in the URL, so anyone who sees the link can decrypt the note, and the fragment is never sent to the server by a browser, which is what keeps the server from seeing it.

Two properties are configurable. Encryption is optional and can be turned on or off per note or for all notes. A frontmatter checkbox called share_unencrypted shares a note in the clear, and if you would rather encrypt most notes by default you can use the opposite frontmatter checkbox called share_encrypted for an individual note.

The boundary is stated clearly as well. Encryption applies to the note text content, and it does not apply to attachments, which are stored unencrypted. Share Note is a note sharing service, and if you want encrypted file sharing it is not the right tool.

Letting a reader save the note into their own vault

There is an option that changes the share from a read-only page into a hand-off, and it is off by default for a reason that is stated.

Turn on Include Markdown source in shared notes in the plugin settings and your shared pages get a Save note button. A reader who has Obsidian and the Share Note plugin can click it and save a copy of the note straight into their own vault, images included.

The reason it is off by default is that the Markdown source shows things the rendered page hides, specifically the frontmatter and any percent-sign comment blocks, which Obsidian uses for notes that are not meant to be read. Encrypted notes keep the source encrypted.

The setting can be overridden per note with a share_source checkbox property, so a single note can include its source while the rest of the vault does not.

That is a thoughtful default. A share link is often pasted into a channel with a wider audience than the note's author intended, and the frontmatter of a personal note can contain things a reader has no business seeing. Making the source opt-in per note rather than per vault is the right granularity, and the checkbox property gives you that without touching the settings.

The documentation site has a page on importing shared notes for the details of the flow.

The disclosures, which are the most unusual part of the README

The disclosures section is the thing to read, and its existence is a signal about the project's maturity.

The section exists because Obsidian's plugin scorecard flags items for transparency, as recommended by the Obsidian developer policies. And it covers three things that would otherwise be reasonable things to be suspicious about in a plugin that uploads your notes somewhere.

On network requests, all requests to the Share Note server, which defaults to https://api.note.sx or your self-hosted instance, go through Obsidian's requestUrl() API, which is the recommended cross-platform HTTP client. Those are necessary for the core sharing, upload and delete operations.

Then there are two fetch() calls in the source file for notes, and the README says they are used only to read local vault assets through Obsidian's app:// protocol, specifically image attachments embedded in a shared note and theme fonts and images referenced from url() declarations in CSS. The reason native fetch is needed is that requestUrl() does not handle the app:// scheme. These calls never reach a remote server.

On base64, the plugin uses btoa() and atob() in two places. One is the crypto module, where the AES-GCM symmetric key and ciphertext are encoded to base64 strings for transport and storage, and the README calls that standard cryptographic serialization rather than string obfuscation. The other is the bundled data-uri-to-buffer dependency, which decodes inline data URIs found in CSS to extract embedded fonts and images for upload. The summary line is that no code is ever loaded, evaluated or transformed at runtime, and no API keys, URLs or strings are hidden via base64.

On clipboard access, the plugin writes the share URL to the system clipboard when you use the Copy shared note link command, and the clipboard is never read.

For a plugin that publishes your vault to a server, this is the section that tells you what it actually does, and it is better than most plugin privacy policies.

Theme upload, self-hosting and the build

The theme handling has a small state machine worth knowing about.

The first time a file is shared, the plugin automatically uploads all your theme styles. The next time you share a file, it uses the previously uploaded theme files. If you want to force the theme CSS to update, there is a command called Force re-upload of all data for this note.

So the theme is uploaded once and reused, which is efficient, and which means a theme change is not picked up until you force it. That is the kind of thing that produces a support question, and the command exists because of it.

Self-hosting is supported through a separate server image published at the note-sx/server repository, and the plugin talks to your own instance instead of the default api.note.sx address. That is what makes the encrypted sharing model work for an organisation that does not want notes passing through a third party service, since the key never leaves the link either way.

The build is a small esbuild project with vitest for tests and eslint for linting. The build script runs lint, then a TypeScript check with noEmit and skipLibCheck, then the tests, then the esbuild production build, so all four gates run on one command. The dev script runs the same esbuild config. There is a separate version-bump script that updates manifest.json and versions.json together, which is how the Obsidian plugin manifest stays in step with the package version. The test environment is happy-dom, and the eslint configuration includes a plugin for Obsidian specific rules.

Where share-note is the wrong choice

The first wrong case is sharing files. The README says it outright, that encryption does not apply to attachments and that this is a note sharing service rather than a file sharing service. If what you need is to send a PDF or an image to someone privately, an encrypted link is the wrong shape, and a file sharing tool with actual encryption is the right one.

The second is a note you cannot unpublish. The key travels in the link and the server never sees it, which is the point, and the cost is that the server cannot help you revoke access to a link you have already sent. Rotating the key for everyone means a new link for everyone, and the old one keeps working until the content itself changes in a way that invalidates it.

The third is a workflow that treats the published page as canonical. The service is a publisher, not a sync target. A page shared today reflects the note as uploaded, and the plugin reuses the previously uploaded theme files, so a page can lag both the note and the theme until you force a re-upload.

The fourth is a compliance review. The disclosures answer the questions a security reviewer would ask about the plugin, but they describe the plugin, not the hosted service, and a hosted service that stores encrypted payloads still sees metadata about which notes exist, when they were shared, and to whom, since the key is only in the fragment.

The alternative worth weighing is publishing the vault yourself. Any static site generator that handles Obsidian notes gives you full control of hosting, no third party, no upload step and no sharing service to reason about, and the cost is that you lose the fidelity work, since a generic Markdown pipeline will not reproduce your theme, your Dataview queries or your callout rendering. That trade is worth making when the notes are the company's rather than yours.

Editorial conclusion

Adopt share-note if you regularly publish notes from a vault and want the result to look like your own reading view rather than a plain HTML export, since the theme, Dataview, callouts and cross-note links all survive, and the encrypted mode keeps the note text unreadable to the hosting server. Keep away if you need attachments encrypted or a self-contained file, because the README states that encryption applies to the note text and not to attachments, and that the tool is a note sharing service rather than a file sharing service. Before you publish anything sensitive, read the disclosures section, since it enumerates the network requests, the two local fetch calls and the base64 usage, and note that the release line is at 1.6.2 from 2026-10-16 with a self-hostable server image available separately.

Frequently asked questions

Official sources

1. alangrainger/share-note on GitHub
2. Issues
3. License: MIT
4. README
5. Releases