Sharing your work

Publishing as a website

File → Export → Vault as Website… compiles an entire vault into a folder of static web pages: every note becomes an .html page, wikilinks turn into real relative links, attachments copy over in place, and a single assets/ folder carries everything the pages need. The result works on any web host — or straight from disk — with no server code, no build step, and no subscription. It is, in short, Obsidian Publish as a menu item.

Running an export

Choose File → Export → Vault as Website… (or the palette command Export vault as website…). Clew asks you to pick a destination folder; the site is written into a subfolder of it named after the vault with a -site suffix — exporting a vault called research into ~/Sites produces ~/Sites/research-site/. A notice appears while the export runs, and when it finishes another gives the page count, the output path, and the number of pages that failed to build, if any.

Every Markdown note in the vault (.md and .jmd) is rendered through the same jmarkdown engine that powers reading mode, with the vault's own render settings applied — so what you see in the app is what the site shows. The vault's folder structure is preserved: Guide/Maps.md becomes Guide/Maps.html. Hidden folders and app internals (.clew/, .obsidian/, .git/, and so on) are skipped. Everything that is not a note — images, PDFs, audio, video, arbitrary attachments — is copied to the same relative location, so nothing a page references goes missing.

The export is fast in a way worth a sentence: each page builds in a fresh engine process, but the next process warms up while the current page renders, so a vault of dozens of notes pays the engine's start-up cost roughly once, not once per note. A page that fails to render does not stop the run; it is recorded and reported at the end, and the rest of the site still builds. As a benchmark, the demo vault that ships with Clew exports to roughly forty pages with zero failures.

How each piece translates

The interesting question about a static export is always what survives the trip. The answer here is: nearly everything you can read, and deliberately nothing you could write.

Links become real links

Inline [[wikilinks]] are rewritten as genuine relative <a href> links to the corresponding pages, correct for each page's depth in the folder tree — a link from Guide/Maps.html up to Welcome.html comes out as ../Welcome.html. Heading links ([[Note#Section]]) carry their anchors along. A wikilink whose target does not exist in the vault is rendered as inert styled text rather than a broken link. Note embeds (![[Note]]) are expanded in place as they are in reading mode, and media embeds point at the copied attachments.

Rendering survives wholesale

Mathematics, theorem environments, citations and bibliographies, footnotes, alerts, mermaid diagrams, media embeds with their sizes — all of it renders on the exported pages exactly as in reading mode, because it is the same engine doing the rendering. The assets/ folder ships local copies of the runtime pieces (MathJax, mermaid, highlighting styles, Font Awesome, jQuery, Leaflet, and the preview stylesheet), so the pages do not depend on a CDN.

Maps stay interactive

Leaflet maps — including photo maps — keep their pins, popups, panning, and zooming. A small static runtime script on every page initialises them against the exported assets. Map tiles still come from the tile server the map uses, as they do in the app.

Figures bake to SVG

TikZ and MetaPost figures are typeset during the export and written into the pages as vector SVG, so a published site carries no engine at all: a visitor loads a few kilobytes of graphics rather than the 74 MB of wasm TeX the app ships, and the server needs no TeX either. Identical figures across pages are typeset once. A figure that fails shows its error log on the page, and the export reports how many did. A figure set in the note's own typeface is baked as glyph outlines rather than text, so the page carries no copy of that font — and looks the same to a visitor who does not have it.

Queries bake to snapshots

Query tables, task lists, and kanban boards are rendered with the data the vault held at export time, then frozen. A published dashboard is a snapshot of the vault the moment you exported — which is exactly what a website should be. What does not carry over is the writing-back: cells are not editable, checkboxes do not toggle, cards do not drag, because the site has no vault to write to.

Vault scripts ship with the site

The vault's shared JavaScript — .clew/scripts/*.js, the vault scripts mechanism — is copied into assets/vault-scripts/ and loaded on every page, in the same alphabetical order as in the app. Custom elements defined there render their content on the published site just as they do in reading mode. Inline scripts written into notes also ship as part of their pages; see the caution below for what they can and cannot do once published.

What deliberately does not carry over

A static site is a collection of documents, and the export is honest about that:

• Anything that writes. Editable query cells, kanban drags, task toggles — every write-back path in the app depends on a running Clew with a vault to rewrite. On the site, those views are static.
• The Note API. Published pages have no window.clew. Note scripts written the recommended way — beginning with a if (!window.clew) return; guard — degrade gracefully into static content (see The Note API).
• Canvas embeds. A ![[board.canvas]] embed appears as a labelled placeholder box, not a live scene — the canvas renderer is part of the app, not of the export runtime.
• Plugins. Preview-surface plugin scripts are an app feature and are not injected into exported pages. (Engine-surface plugins, by contrast, do take effect, since the pages are rendered by the same configured engine — any custom syntax they add renders into the exported HTML.)
• Editing, search, backlink panels, the graph — the app around the notes, in general.

The home page

Alongside the per-note pages, the export creates an index.html so the site has a front door. It is a copy of the first of these notes found at the vault root: Welcome.md, Start Here.md, Home.md, or index.md — and failing all four, the first note the export encountered, provided it sits at the root. If nothing qualifies, no index.html is produced; give the vault a root-level Welcome.md (a good idea anyway — see Vaults and files) and it becomes the landing page.

Hosting the result

The output folder is self-contained static HTML: any web host that can serve files can serve it. Copy it to GitHub Pages, Netlify, an S3 bucket, the public_html of a university account, or a Raspberry Pi running nginx — there is no server component, no database, and no build pipeline to install. The pages also open directly from disk, so double-clicking index.html is a perfectly good way to check the export before uploading it.

Re-exporting after you change the vault is the whole publishing workflow: run the menu item again and upload the folder. Because the site is a pure function of the vault, there is no separate content management step — the vault is the CMS.

Reference

See also

• Exporting notes — single-note HTML, LaTeX, and PDF export, which uses a different pipeline on purpose.
• Queries and Tasks and kanban — the live views that bake to snapshots.
• Interactive maps — which stay interactive on the site.
• The Note API — writing note scripts that degrade gracefully when published.
• Vault plugins — including the vault scripts that ship with the site.