Markpad: a Notepad-weight Markdown editor built on Tauri and SvelteKit

A two-pane editor with a live preview

Markpad is described as light as Notepad and elegant as Markdown, and it is a lightweight, minimalist Markdown viewer and text editor built for productivity across Windows, macOS and Linux.

The shape is the familiar one: an editor pane on the left, a rendered preview on the right. The editor is Monaco, the same engine as VS Code, with Vim support through monaco-vim, and the split view is kept in sync line for line. The rendering is GitHub-styled, with syntax highlighting in code blocks.

The dependency list in the manifest shows the stack. It is SvelteKit with Svelte 5 and Vite 6 for the interface, Tauri 2 for the desktop shell, and the Rust side is in `src-tauri/`. The rendering libraries are the well-known ones: highlight.js for code blocks with a Svelte-specific package for the integration, KaTeX for maths, Mermaid for diagrams, and dompurify for sanitising the HTML that comes out of the renderer.

That last one matters more than it looks. A Markdown editor that renders user content in a webview is running a browser engine over content that may come from anywhere, and dompurify is there to make sure a document cannot execute what it should not. The dependency is pinned exactly at 3.4.16 rather than with a caret, and there is an `overrides` block in the manifest pinning `dompurify` and `cookie` to specific versions, which is the practice you would expect from a project that takes the sanitisation path seriously.

The licence is BSD-3-Clause, the version in the manifest is 2.8.4, and the last push was on 2026-10-14 with v2.8.4 tagged on 2026-10-07.

Reading and editing features, and the syntax document

The feature list is split into four groups, and the reading group is where the differentiation sits.

For reading, there is GitHub-styled rendering with syntax highlighting in code blocks, maths via KaTeX and diagrams via Mermaid, a table of contents that follows wherever you scroll, folding by heading, and a Zen mode with everything else out of the way. Content zoom, custom typography and custom themes are there too, with VS Code themes importable.

For editing, Monaco with Vim support, the synchronised split view, heading completion for links, a customisable formatting toolbar, and the ability to paste an image straight into the document or drag files in to open them.

For documents, tabs, multiple windows, window tags and a session that comes back, plus a Home page with recent files and pinned tags that reopen a saved group of files. Auto-reload when a file changes on disk handles the case where the same Markdown file is edited by another tool. Export to HTML and print to PDF are there, and alongside standard Markdown there are wikilinks, embeds and callouts.

That last group is the one that makes it more than a text editor with a preview, and it is also the one with a design problem. Wikilinks and callouts are conventions from a particular note-taking ecosystem, and a renderer that supports them has to make choices the Markdown spec does not make. The README's answer to that is the `samples/markdown-syntax.md` document, which says every syntax Markpad renders is in one document, and that the preview shows each feature working while the editor beside it shows how each one is written.

That is a clever distribution trick. The sample file is both documentation and a test fixture, and the README goes further, suggesting you give the same file to an AI and it will know exactly what Markpad can render, which is a way of turning a syntax reference into a prompt for generating documents. The `samples/` directory also holds encoding tests for CP1252, GBK and Shift-JIS, a KaTeX stress file and a link test.

Install paths and the update trap

There are three package managers and a set of direct downloads, and the difference between them matters more than usual here.

brew install --cask markpad

sudo snap install markpad

and on Windows, `choco install markpad-app`.

The direct downloads cover the rest. On Windows there is an installer, `Markpad_x.y.z_x64-setup.exe`, and a portable build, `Markpad_x.y.z_x64.exe`, with the same for ARM64. The two Windows files differ only in that one installs and one does not, with the setup variant putting Markpad in Program Files and the Start menu. macOS gets a single universal dmg for both Intel and Apple Silicon. Linux gets an x86-64 AppImage, a deb for Debian and Ubuntu, and an rpm for Fedora, RHEL and openSUSE.

The update behaviour is where the care is needed. After a direct dmg or Homebrew install, the macOS NSIS or AppImage-style install, or a Windows `*-setup.exe`, Markpad self-updates from GitHub releases through the in-app Check for Updates entry, which lives in the macOS app menu or in Settings elsewhere. Chocolatey and Snap keep Markpad current through those package managers instead.

The deb and rpm are the exception, and the README says so plainly. `tauri-plugin-updater` cannot replace a package-managed install, and there is no apt or dnf repository to update from, so upgrading means downloading a newer package from the releases page. Check for Updates recognises a package-managed install and tells you so.

So a Linux user on Debian or Fedora ends up with a package that never updates itself. That is a reasonable design, since mixing the two mechanisms is how you get a broken installation, but it means the update habit is on you.

Building from source and the isolated macOS bundle

The source build is four steps. Clone the repository, run `npm install` to install dependencies, and run `npm run tauri build` to build the executable.

There is one more command that is worth knowing about, aimed at contributors rather than users:

MARKPAD_TEST_BUNDLE_ID=dev.example.markpad.test npm run build:test-bundle

The script is `node scripts/build-test-bundle.mjs` in the manifest. It exists so you can verify a change without opening or replacing `/Applications/Markpad.app`, by building an unsigned test-only app with an independent bundle identifier. The result lands in `dist/test-bundle/`, and the README is explicit that it is not a distributable release because it has no Developer ID notarization and no Windows Authenticode signature.

That is a detail that suggests a careful release process, and the repository has the paperwork for it. There is a `RELEASING.md`, a `snapcraft.yaml` for the Snap package, a `packaging/` directory for the per-platform packages, a `scripts/` directory that includes `release.mjs`, and a `FUNDING.yml`.

The test setup is also more layered than a typical small project. There is `node --test --import tsx` running the scripts tests, Vitest for the unit tests, a `test:frontmatter` target for the front matter parsing, and a `test:workflows` target that covers the HTML export, the OpenPrompt export and the two toolbars.

For the contributing workflow, the README lists the steps: fork and clone, `npm install`, `npm run tauri dev` to run the app locally, make your changes and ensure type checking passes with `npm run check`, then open a pull request. The `check` script is `svelte-kit sync && svelte-check --tsconfig ./tsconfig.json`.

Editorial conclusion

Markpad fits someone who wants a Markdown preview that keeps up as they type, on all three major desktop platforms, without a browser tab or a subscription. It does not fit a writer who needs collaborative editing, a note base with backlinks across a vault, or a stable release channel, since the deb and rpm packages never update themselves. Before installing, pick the package that matches how you update software, because the self-updater works for the dmg, AppImage and portable Windows builds but not for the deb or rpm, and check the samples/markdown-syntax.md file to see everything the renderer supports.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. sftwrdotdev/Markpad on GitHub